From gcc-return-8653-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 07:00:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27522 invoked by alias); 1 Aug 1999 07:00:30 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27514 invoked from network); 1 Aug 1999 07:00:25 -0000 Received: from law2-oe16.hotmail.com (HELO hotmail.com) (216.32.180.120) by egcs.cygnus.com with SMTP; 1 Aug 1999 07:00:25 -0000 Received: (qmail 86030 invoked by uid 65534); 1 Aug 1999 06:58:36 -0000 Message-ID: <19990801065836.86029.qmail@hotmail.com> X-Originating-IP: [202.139.12.105] From: "Stewart Mohr" To: Subject: GCC 2.95 succcessfully built and installed on i586-pc-linux-gnu Date: Sun, 1 Aug 1999 16:28:51 +0930 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01BEDC3A.F0609D30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2918.2701 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701 This is a multi-part message in MIME format. ------=_NextPart_000_001D_01BEDC3A.F0609D30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No problems at all. Source file : gcc-2.95.tar.gz2 config.guess output : i586-pc-linux-gnu Cheers Stewart Mohr ------=_NextPart_000_001D_01BEDC3A.F0609D30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
No problems at all.
 
Source file : = gcc-2.95.tar.gz2
config.guess=20 output : i586-pc-linux-gnu
 
Cheers
Stewart = Mohr
------=_NextPart_000_001D_01BEDC3A.F0609D30-- From gcc-return-8654-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 07:11:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28543 invoked by alias); 1 Aug 1999 07:11:01 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28531 invoked from network); 1 Aug 1999 07:10:59 -0000 Received: from law2-oe8.hotmail.com (HELO hotmail.com) (216.32.180.112) by egcs.cygnus.com with SMTP; 1 Aug 1999 07:10:59 -0000 Received: (qmail 51778 invoked by uid 65534); 1 Aug 1999 07:09:07 -0000 Message-ID: <19990801070907.51777.qmail@hotmail.com> X-Originating-IP: [202.139.12.105] From: "Stewart Mohr" To: Subject: GCC 2.95 succcessfully built and installed on i586-pc-linux-gnu Date: Sun, 1 Aug 1999 16:39:33 +0930 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2918.2701 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2918.2701 No problems at all. Source file : gcc-2.95.tar.gz2 config.guess output : i586-pc-linux-gnu Cheers Stewart Mohr From gcc-return-8655-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 07:34:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30876 invoked by alias); 1 Aug 1999 07:34:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30862 invoked from network); 1 Aug 1999 07:34:43 -0000 Received: from thor.xraylith.wisc.edu (198.150.6.11) by egcs.cygnus.com with SMTP; 1 Aug 1999 07:34:43 -0000 Received: from mercury.xraylith.wisc.edu (mercury.xraylith.wisc.edu [128.104.182.221]) by thor.xraylith.wisc.edu (8.9.1a/8.9.1) with ESMTP id CAA09731 for ; Sun, 1 Aug 1999 02:33:12 -0500 Received: from mercury.xraylith.wisc.edu (localhost [127.0.0.1]) by mercury.xraylith.wisc.edu (8.8.7/8.8.7) with ESMTP id BAA00927 for ; Sun, 1 Aug 1999 01:23:51 -0500 Message-Id: <199908010623.BAA00927@mercury.xraylith.wisc.edu> To: gcc@gcc.gnu.org Subject: link from www.gnu.org -> gcc.gnu.org Date: Sun, 01 Aug 1999 01:23:51 -0500 From: Mumit Khan Looking at http://www.gnu.org/software/gcc/, there is no obvious link to gcc.gnu.org. I hope this discontinuity is fixed soon, since all the real useful info is on gcc.gnu.org (such as the FAQ, build info and so on). This link should prominently be featured in the News section. The other nit is the pointer to vger.rutgers.edu as the snapshot location, obviously a holdover from gcc-2.x days. Regards, Mumit From gcc-return-8656-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 08:23:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3215 invoked by alias); 1 Aug 1999 08:23:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3208 invoked from network); 1 Aug 1999 08:23:51 -0000 Received: from hq.alert.sk (qmailr@147.175.66.131) by egcs.cygnus.com with SMTP; 1 Aug 1999 08:23:51 -0000 Received: (qmail 23238 invoked by uid 608); 1 Aug 1999 08:23:18 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Aug 1999 08:23:18 -0000 Date: Sun, 1 Aug 1999 10:23:18 +0200 (CEST) From: Niteshadow To: gcc@gcc.gnu.org Subject: gcc-2.95 built on i686-pc-linux-gnu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Successful build of the gcc-2.95.tar.bz2 package with default options on: i686-pc-linux-gnu (glibc-2.1.1) i586-pc-linux-gnu (glibc-2.0.7) Signed Robert ------------------------------------------------------------------------------ >From : Robert 'Niteshadow' Varga email : niteshadow@hq.alert.sk, varga@ibl.sk PGPkey: http://hq.alert.sk/~niteshadow/pgpkey.txt ------------------------------------------------------------------------------ We are Linux. Resistance means you didn't get the point. From gcc-return-8657-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 08:43:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5330 invoked by alias); 1 Aug 1999 08:43:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5323 invoked from network); 1 Aug 1999 08:43:45 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 1 Aug 1999 08:43:45 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id KAA10450; Sun, 1 Aug 1999 10:38:24 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id KAA17265; Sun, 1 Aug 1999 10:35:49 +0200 Date: Sun, 1 Aug 1999 10:35:49 +0200 Message-Id: <199908010835.KAA17265@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: omar@axe.net.au CC: gcc@gcc.gnu.org In-reply-to: (message from Omar Kilani on Sun, 1 Aug 1999 00:58:05 +1000 (EST)) Subject: Re: gcc 2.8.1 bug? or ... References: User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.3.92 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > I hope I'm not posting to the wrong list ... but I seem to be having a > parculiar problem with gcc 2.8.1 (and egcs 1.1.3). It would seem that, > when the attached program (testconf) is compiled it produces the following > output (compiled with 2.8.1): Thanks for your bug report. I had problems reproducing that bug. Are you sure you are using egcs 1.1.3? - There was no such release, only egcs 1.1.2. Perhaps you use egcs 1.0.3? Anyway, I could not reproduce it with egcs 1.1.2, nor with gcc 2.95, on a Redhat 5.0 system (glibc 2.1.1). It is entirely possible that this was a bug in egcs 1.0. I recommend upgrading your compiler (rather than downgrading); if you keep getting the errors, please report again. Thanks, Martin From gcc-return-8658-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 08:58:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6966 invoked by alias); 1 Aug 1999 08:58:07 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6959 invoked from network); 1 Aug 1999 08:58:05 -0000 Received: from ethel.as.arizona.edu (HELO arcturus.as.arizona.edu) (128.196.209.142) by egcs.cygnus.com with SMTP; 1 Aug 1999 08:58:05 -0000 Received: from physics.arizona.edu (fieldsey@localhost [127.0.0.1]) by arcturus.as.arizona.edu (8.9.1/8.9.1) with ESMTP id BAA21440 for ; Sun, 1 Aug 1999 01:57:49 -0700 Message-ID: <37A40C0B.2AC7DBB7@physics.arizona.edu> Date: Sun, 01 Aug 1999 01:57:47 -0700 From: Jason Fields Organization: SkyBlu Command X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.6 i586) X-Accept-Language: en, fr MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: gcc-2.95 build successful Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I successfully built gcc-2.95 on a i586-pc-linux-gnu computer. fieldsey out -- Reality is not merely warped, it's bent. From gcc-return-8659-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 09:46:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11672 invoked by alias); 1 Aug 1999 09:46:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11658 invoked from network); 1 Aug 1999 09:46:38 -0000 Received: from linuxpc1.lauterbach.com (qmailr@194.195.165.177) by egcs.cygnus.com with SMTP; 1 Aug 1999 09:46:38 -0000 Received: (qmail 6423 invoked from network); 1 Aug 1999 09:44:58 -0000 Received: from ns1142.munich.netsurf.de (HELO ns1102.munich.netsurf.de) (195.180.235.142) by linuxpc1 with SMTP; 1 Aug 1999 09:44:58 -0000 From: Franz Sirl To: Arvind Sankar Subject: On the RPM-spec (was: Re: gcc-2.95: Naming of the TAR file? GCC-2.95.tar.gz? gcc-2.95.tar.gz?) Date: Sun, 1 Aug 1999 11:17:57 +0200 X-Mailer: KMail [version 1.0.27] Content-Type: Multipart/Mixed; boundary="Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD" Cc: gcc@gcc.gnu.org References: <422.932833762@upchuck.cygnus.com> <99072510340200.00493@ns1102.munich.netsurf.de> <19990725110354.B14520@anjala.mit.edu> In-Reply-To: <19990725110354.B14520@anjala.mit.edu> MIME-Version: 1.0 Message-Id: <99080111452700.00528@ns1102.munich.netsurf.de> --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD Content-Type: text/plain Content-Transfer-Encoding: 8bit Am Son, 25 Jul 1999 schrieb Arvind Sankar: >>While on the subject of making an RPM, I used to make RPMS from the >snapshots for RedHat Contrib|Net, and I've attached the .spec file and >patches I needed. The .spec makes a couple of additional info files, runs >the testsuite and packages the results, and adds libgcj to the RPM. Well, your spec is very similar to mine, the 2 basic differences are: 1. you configure for an optional compiler in /opt/egcs, I configure for a system compiler in /usr 2. you follow the old RH5 layout (with libstdc++-devel), I follow the the RH6 layout (with libstdc++-devel merged into gcc-c++ and a separate cpp) I don't care about about not-installed info files, because I believe they are not installed on purpose :-). I only make sure that all info files are built with --no-split to reduce the clutter in the info dir. In the meantime, following some other discussions, I think the best approach would really be to have 2 separate specs, one for use as a system compiler (like mine) and one for use as an optional compiler (in /opt/gcc, /usr/local, etc), cause the requirements during install are quite different. The purpose/pitfalls of each spec should be clearly documented in it's header. I already integrated some stuff out of your spec into my spec, and your spec needs some overhaul egcs -> gcc :-). The only real nits I found in your spec, you are building inside the sourcedir and you don't support any multilibbed target yet (look for %ifarch ppc/alpha in my spec). I think we should synchronize a bit and then put up the specs for download (maybe in the FTP infrastructure dir, with links from the FAQ/install pages). What do you think? Franz. --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD Content-Type: text/english; name="gcc-2.95-usr.spec" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gcc-2.95-usr.spec" IwojIHRoaXMgc3BlYy1maWxlIHJlcXVpcmVzIHJwbS0zLjAgb3IgbmV3ZXIKIwolZGVmaW5lIEdD Q19WRVJTSU9OIDIuOTUKJWRlZmluZSBTVERDX1ZFUlNJT04gMi4xMC4wCiVkZWZpbmUgdGFyZ2V0 X2FsaWFzICV7X3RhcmdldF9jcHV9LWxpbnV4CiVkZWZpbmUgT0JKRElSICRSUE1fQlVJTERfRElS L29iai1nY2MtJFJQTV9BUkNICgpTdW1tYXJ5OiBHTlUgQ29tcGlsZXIgQ29sbGVjdGlvbiAtIENv cmUgcGFja2FnZSBpbmNsdWRpbmcgQyBjb21waWxlcgpOYW1lOiBnY2MKVmVyc2lvbjogJXtHQ0Nf VkVSU0lPTn0KUmVsZWFzZTogMApDb3B5cmlnaHQ6IEdQTApHcm91cDogRGV2ZWxvcG1lbnQvTGFu Z3VhZ2VzClNvdXJjZTogZnRwOi8vZ2NjLmdudS5vcmcvcHViL2djYy9yZWxlYXNlcy9nY2MtJXtH Q0NfVkVSU0lPTn0vZ2NjLSV7R0NDX1ZFUlNJT059LnRhci5negpCdWlsZHJvb3Q6IC92YXIvdG1w L2djYy0le0dDQ19WRVJTSU9OfS1yb290ClVybDogaHR0cDovL2djYy5nbnUub3JnLwpSZXF1aXJl czogY3BwID0gJXtHQ0NfVkVSU0lPTn0KJWlmYXJjaCBwcGMKUmVxdWlyZXM6IGJpbnV0aWxzID49 IDIuOS40LjAuOAolZWxzZQpSZXF1aXJlczogYmludXRpbHMgPj0gMi45LjEuMC4yMwolZW5kaWYK T2Jzb2xldGVzOiBlZ2NzClByZXJlcTogL3NiaW4vaW5zdGFsbC1pbmZvCgolZGVzY3JpcHRpb24K R0NDLCB0aGUgR05VIENvbXBpbGVyIENvbGxlY3Rpb24sIGlzIGEgZnJlZSBzb2Z0d2FyZSBwcm9q ZWN0IHRoYXQgaW50ZW5kcyB0bwpmdXJ0aGVyIHRoZSBkZXZlbG9wbWVudCBvZiBHTlUgY29tcGls ZXJzIHVzaW5nIGFuIG9wZW4gZGV2ZWxvcG1lbnQKZW52aXJvbm1lbnQuIFRoZSBnY2MgcGFja2Fn ZSBjb250YWlucyB0aGUgR0NDIEMgY29tcGlsZXIsIGEgY29tcGlsZXIgYWltZWQKYXQgaW50ZWdy YXRpbmcgYWxsIHRoZSBvcHRpbWl6YXRpb25zIGFuZCBmZWF0dXJlcyBuZWNlc3NhcnkgZm9yIGEK aGlnaC1wZXJmb3JtYW5jZSBhbmQgc3RhYmxlIGRldmVsb3BtZW50IGVudmlyb25tZW50LgoKSW5z dGFsbCBnY2MgaWYgeW91J2QgbGlrZSB0byB1c2UgdGhlIEdOVSBDb21waWxlciBDb2xsZWN0aW9u IEMgY29tcGlsZXIsIHlvdQp3aWxsIGFsc28gbmVlZCB0byBpbnN0YWxsIHRoZSBjcHAgcGFja2Fn ZS4KCiVwYWNrYWdlIC1uIGNwcApTdW1tYXJ5OiBHTlUgQ29tcGlsZXIgQ29sbGVjdGlvbiAtIFRo ZSBDIFByZXByb2Nlc3Nvci4KR3JvdXA6IERldmVsb3BtZW50L0xhbmd1YWdlcwpQcmVyZXE6IC9z YmluL2luc3RhbGwtaW5mbwoKJWRlc2NyaXB0aW9uIC1uIGNwcApUaGUgQyBwcmVwcm9jZXNzb3Ig aXMgYSAnbWFjcm8gcHJvY2Vzc29yJyB3aGljaCBpcyB1c2VkIGF1dG9tYXRpY2FsbHkKYnkgdGhl IEMgY29tcGlsZXIgdG8gdHJhbnNmb3JtIHlvdXIgcHJvZ3JhbSBiZWZvcmUgYWN0dWFsCmNvbXBp bGF0aW9uLiBJdCBpcyBjYWxsZWQgYSBtYWNybyBwcm9jZXNzb3IgYmVjYXVzZSBpdCBhbGxvd3MK eW91IHRvIGRlZmluZSAnbWFjcm9zJywgd2hpY2ggYXJlIGFiYnJldmlhdGlvbnMgZm9yIGxvbmdl cgpjb25zdHJ1Y3RzLgoKVGhlIEMgcHJlcHJvY2Vzc29yIHByb3ZpZGVzIGZvdXIgc2VwYXJhdGUg ZmFjaWxpdGllcyB0aGF0IHlvdSBjYW4gdXNlIGFzCnlvdSBzZWUgZml0OgoKKiBJbmNsdXNpb24g b2YgaGVhZGVyIGZpbGVzLiBUaGVzZSBhcmUgZmlsZXMgb2YgZGVjbGFyYXRpb25zIHRoYXQgY2Fu IGJlCiAgc3Vic3RpdHV0ZWQgaW50byB5b3VyIHByb2dyYW0uCiogTWFjcm8gZXhwYW5zaW9uLiBZ b3UgY2FuIGRlZmluZSAnbWFjcm9zJywgd2hpY2ggYXJlIGFiYnJldmlhdGlvbnMgZm9yCiAgYXJi aXRyYXJ5IGZyYWdtZW50cyBvZiBDIGNvZGUsIGFuZCB0aGVuIHRoZSBDIHByZXByb2Nlc3NvciB3 aWxsIHJlcGxhY2UKICB0aGUgbWFjcm9zIHdpdGggdGhlaXIgZGVmaW5pdGlvbnMgdGhyb3VnaG91 dCB0aGUgcHJvZ3JhbS4KKiBDb25kaXRpb25hbCBjb21waWxhdGlvbi4gVXNpbmcgc3BlY2lhbCBw cmVwcm9jZXNzaW5nIGRpcmVjdGl2ZXMsCiAgeW91IGNhbiBpbmNsdWRlIG9yIGV4Y2x1ZGUgcGFy dHMgb2YgdGhlIHByb2dyYW0gYWNjb3JkaW5nIHRvIHZhcmlvdXMKICBjb25kaXRpb25zLgoqIExp bmUgY29udHJvbC4gSWYgeW91IHVzZSBhIHByb2dyYW0gdG8gY29tYmluZSBvciByZWFycmFuZ2Ug c291cmNlIGZpbGVzCiAgaW50byBhbiBpbnRlcm1lZGlhdGUgZmlsZSB3aGljaCBpcyB0aGVuIGNv bXBpbGVkLCB5b3UgY2FuIHVzZSBsaW5lCiAgY29udHJvbCB0byBpbmZvcm0gdGhlIGNvbXBpbGVy IGFib3V0IHdoZXJlIGVhY2ggc291cmNlIGxpbmUgb3JpZ2luYXRlZC4KCllvdSBzaG91bGQgaW5z dGFsbCB0aGlzIHBhY2thZ2UgaWYgeW91IGFyZSBhIHByb2dyYW1tZXIgd2hvIGlzIHNlYXJjaGlu ZyBmb3IKc3VjaCBhIG1hY3JvIHByb2Nlc3Nvci4KCiVwYWNrYWdlIGMrKwpTdW1tYXJ5OiBDKysg c3VwcG9ydCBmb3IgdGhlIEdOVSBDb21waWxlciBDb2xsZWN0aW9uLgpHcm91cDogRGV2ZWxvcG1l bnQvTGFuZ3VhZ2VzClJlcXVpcmVzOiBjcHAgPSAle0dDQ19WRVJTSU9OfQpSZXF1aXJlczogZ2Nj ID0gJXtHQ0NfVkVSU0lPTn0KUmVxdWlyZXM6IGxpYnN0ZGMrKyA9ICV7U1REQ19WRVJTSU9OfQpP YnNvbGV0ZXM6IGVnY3MtYysrCk9ic29sZXRlczogbGlic3RkYysrLWRldmVsCk9ic29sZXRlczog bGliZysrLWRldmVsCgolZGVzY3JpcHRpb24gYysrClRoaXMgcGFja2FnZSBhZGRzIEMrKyBzdXBw b3J0IHRvIHRoZSBHTlUgY29tcGlsZXIgY29sbGVjdGlvbi4gSXQgaW5jbHVkZXMKc3VwcG9ydCBm b3IgbW9zdCBvZiB0aGUgY3VycmVudCBDKysgc3BlY2lmaWNhdGlvbiwgaW5jbHVkaW5nIHRlbXBs YXRlcyBhbmQKZXhjZXB0aW9uIGhhbmRsaW5nLiBJdCBkb2VzIGluY2x1ZGUgdGhlIHN0YXRpYyBz dGFuZGFyZCBDKysgbGlicmFyeSBhbmQgQysrCmhlYWRlciBmaWxlczsgdGhlIGxpYnJhcnkgZm9y IGR5bmFtaWNhbGx5IGxpbmtpbmcgcHJvZ3JhbXMgaXMgYXZhaWxhYmxlCnNlcGFyYXRlbHkuCgol cGFja2FnZSBvYmpjClN1bW1hcnk6IE9iamVjdGl2ZSBDIHN1cHBvcnQgZm9yIHRoZSBHTlUgQ29t cGlsZXIgQ29sbGVjdGlvbi4KR3JvdXA6IERldmVsb3BtZW50L0xhbmd1YWdlcwpSZXF1aXJlczog Y3BwID0gJXtHQ0NfVkVSU0lPTn0KUmVxdWlyZXM6IGdjYyA9ICV7R0NDX1ZFUlNJT059ClJlcXVp cmVzOiBnY2MtYysrID0gJXtHQ0NfVkVSU0lPTn0KT2Jzb2xldGVzOiBlZ2NzLW9iamMKCiVkZXNj cmlwdGlvbiBvYmpjCk9iamVjdGl2ZSBDIGlzIGFuIG9iamVjdC1vcmllbnRlZCBkZXJpdmF0aXZl IG9mIHRoZSBDIGxhbmd1YWdlLCBtdWNoIGxpa2UKQysrIGJ1dCB3aXRoIG1vcmUgZHluYW1pYyBj YXBhYmlsaXRpZXMgdGhhbiB0aGlzLiBUaGlzIHBhY2thZ2UgYWRkcwpPYmplY3RpdmUtQyBzdXBw b3J0IHRvIHRoZSBHTlUgQ29tcGlsZXIgQ29sbGVjdGlvbi4gSXQgaW5jbHVkZXMgdGhlCk9iamVj dGl2ZS1DIGNvbXBpbGVyIGFuZCBydW50aW1lIHRoYXQgaXMgbmVlZGVkIGZvciBydW5uaW5nIE9i amVjdGl2ZS1DCnByb2dyYW1zLgoKSW5zdGFsbCBnY2Mtb2JqYyBpZiB5b3UgYXJlIGdvaW5nIHRv IGRvIE9iamVjdGl2ZSBDIGRldmVsb3BtZW50IGFuZCB5b3UKd291bGQgbGlrZSB0byB1c2UgdGhl IEdOVSBDb21waWxlciBDb2xsZWN0aW9uLiAgWW91IHdpbGwgYWxzbyBuZWVkIHRvCmluc3RhbGwg dGhlIGdjYyBwYWNrYWdlLgoKJXBhY2thZ2UgZzc3ClN1bW1hcnk6IEZvcnRyYW4gNzcgc3VwcG9y dCBmb3IgdGhlIEdOVSBDb21waWxlciBDb2xsZWN0aW9uLgpHcm91cDogRGV2ZWxvcG1lbnQvTGFu Z3VhZ2VzClJlcXVpcmVzOiBjcHAgPSAle0dDQ19WRVJTSU9OfQpSZXF1aXJlczogZ2NjID0gJXtH Q0NfVkVSU0lPTn0KT2Jzb2xldGVzOiBlZ2NzLWc3NwpQcmVyZXE6IC9zYmluL2luc3RhbGwtaW5m bwoKJWRlc2NyaXB0aW9uIGc3NwpUaGUgZ2NjLWc3NyBwYWNrYWdlIHByb3ZpZGVzIHN1cHBvcnQg Zm9yIGNvbXBpbGluZyBGb3J0cmFuIDc3IHByb2dyYW1zIHdpdGgKdGhlIEdOVSBDb21waWxlciBD b2xsZWN0aW9uLgoKWW91IHNob3VsZCBpbnN0YWxsIGdjYy1nNzcgaWYgeW91IGFyZSBnb2luZyB0 byBkbyBGb3J0cmFuIGRldmVsb3BtZW50IGFuZAp5b3Ugd291bGQgbGlrZSB0byB1c2UgdGhlIEdO VSBDb21waWxlciBDb2xsZWN0aW9uLiAgWW91IHdpbGwgYWxzbyBuZWVkIHRvCmluc3RhbGwgdGhl IGdjYyBwYWNrYWdlLgoKJXBhY2thZ2UgamF2YQpTdW1tYXJ5OiBKYXZhIHN1cHBvcnQgZm9yIHRo ZSBHTlUgQ29tcGlsZXIgQ29sbGVjdGlvbi4KR3JvdXA6IERldmVsb3BtZW50L0xhbmd1YWdlcwpS ZXF1aXJlczogY3BwID0gJXtHQ0NfVkVSU0lPTn0KUmVxdWlyZXM6IGdjYyA9ICV7R0NDX1ZFUlNJ T059ClJlcXVpcmVzOiBsaWJnY2oKUHJlcmVxOiAvc2Jpbi9pbnN0YWxsLWluZm8KCiVkZXNjcmlw dGlvbiBqYXZhClRoZSBnY2MtamF2YSBwYWNrYWdlIHByb3ZpZGVzIHN1cHBvcnQgZm9yIGNvbXBp bGluZyBKYXZhIHByb2dyYW1zCndpdGggdGhlIEdOVSBDb21waWxlciBDb2xsZWN0aW9uLgoKWW91 IHNob3VsZCBpbnN0YWxsIGdjYy1qYXZhIGlmIHlvdSBhcmUgZ29pbmcgdG8gZG8gSmF2YSBkZXZl bG9wbWVudCBhbmQgeW91CndvdWxkIGxpa2UgdG8gdXNlIHRoZSBHTlUgQ29tcGlsZXIgQ29sbGVj dGlvbi4gIFlvdSB3aWxsIGFsc28gbmVlZCB0bwppbnN0YWxsIHRoZSBnY2MgcGFja2FnZSBhbmQg dGhlIGxpYmdjaiBwYWNrYWdlLgoKJXBhY2thZ2UgY2hpbGwKU3VtbWFyeTogQ2hpbGwgc3VwcG9y dCBmb3IgdGhlIEdOVSBDb21waWxlciBDb2xsZWN0aW9uLgpHcm91cDogRGV2ZWxvcG1lbnQvTGFu Z3VhZ2VzClJlcXVpcmVzOiBjcHAgPSAle0dDQ19WRVJTSU9OfQpSZXF1aXJlczogZ2NjID0gJXtH Q0NfVkVSU0lPTn0KUHJlcmVxOiAvc2Jpbi9pbnN0YWxsLWluZm8KCiVkZXNjcmlwdGlvbiBjaGls bApUaGUgZ2NjLWNoaWxsIHBhY2thZ2UgcHJvdmlkZXMgc3VwcG9ydCBmb3IgY29tcGlsaW5nIENo aWxsIHByb2dyYW1zIHdpdGggdGhlCkdOVSBDb21waWxlciBDb2xsZWN0aW9uLiBDaGlsbCBpcyB0 aGUgIkNDSVRUIEhpZ2gtTGV2ZWwgTGFuZ3VhZ2UiLCB3aGVyZQpDQ0lUVCBpcyB0aGUgb2xkIG5h bWUgZm9yIHdoYXQgaXMgbm93IElUVSwgdGhlIEludGVybmF0aW9uYWwKVGVsZWNvbW11bmljYXRp b25zIFVuaW9uLiBJdCBpcyBpcyBsYW5ndWFnZSBpbiB0aGUgTW9kdWxhMiBmYW1pbHksIGFuZAp0 YXJnZXRzIG1hbnkgb2YgdGhlIHNhbWUgYXBwbGljYXRpb25zIGFzIEFkYSAoZXNwZWNpYWxseSBs YXJnZSBlbWJlZGRlZApzeXN0ZW1zKS4gQ2hpbGwgd2FzIG5ldmVyIHVzZWQgbXVjaCBpbiB0aGUg VW5pdGVkIFN0YXRlcywgYnV0IGlzIHN0aWxsIGJlaW5nCnVzZWQgaW4gRXVyb3BlLCBCcmF6aWws IEtvcmVhLCBhbmQgb3RoZXIgcGxhY2VzLgoKWW91IHdpbGwgYWxzbyBuZWVkIHRvIGluc3RhbGwg dGhlIGdjYyBwYWNrYWdlLgoKJXBhY2thZ2UgLW4gbGlic3RkYysrClN1bW1hcnk6IGMrKyBsaWJy YXJ5IGZvciB0aGUgR05VIENvbXBpbGVyIENvbGxlY3Rpb24uCkdyb3VwOiBTeXN0ZW0gRW52aXJv bm1lbnQvTGlicmFyaWVzCk9ic29sZXRlczogbGliZysrClZlcnNpb246ICV7U1REQ19WRVJTSU9O fQoKJWRlc2NyaXB0aW9uIC1uIGxpYnN0ZGMrKwpHTlUgQysrIHJ1bnRpbWUgbGlicmFyaWVzCgol cHJlcAolc2V0dXAgLXEKIyB3ZSBkb24ndCBuZWVkIHRvIGJ1aWxkIHRleGluZm8gb24gYSBjdXJy ZW50IExpbnV4IGluc3RhbGxhdGlvbgpybSAtcmYgdGV4aW5mbwoKJWJ1aWxkClNSQ0RJUj0iJFBX RCIKcm0gLXJmICV7T0JKRElSfQpta2RpciAle09CSkRJUn0KY2QgJXtPQkpESVJ9CgokU1JDRElS L2NvbmZpZ3VyZSBcCgktLXByZWZpeD0vdXNyIFwKCS0tZW5hYmxlLXNoYXJlZCBcCgktLWVuYWJs ZS10aHJlYWRzIFwKCS0td2l0aC1jcHAtaW5zdGFsbC1kaXI9Li4vbGliIFwKCSV7dGFyZ2V0X2Fs aWFzfSAyPiYxIHwgdGVlICRTUkNESVIvYnVpbGQubG9nCgpleHBvcnQgUEFUSD0kUEFUSDovc2Jp bjovdXNyL3NiaW4KCm1ha2UgYm9vdHN0cmFwLWxlYW4gMj4mMSB8IHRlZSAtYSAkU1JDRElSL2J1 aWxkLmxvZwoKIyB3b3JrYXJvdW5kIGEgYnVnIGluIHRoZSBoYW5kbGluZyBvZiBNQUtFSU5GTyBp biBnY2MtMi45NQpmaW5kIC1uYW1lICIqLmluZm8ifHhhcmdzIHJtIC1mCmZpbmQgLW5hbWUgIiou aW5mby1bMS05XSoifHhhcmdzIHJtIC1mCm1ha2UgaW5mbyBNQUtFSU5GTz0ibWFrZWluZm8gLS1u by1zcGxpdCIgfCB0ZWUgLWEgJFNSQ0RJUi9idWlsZC5sb2cKCmlmIFsgLXggL3Vzci9iaW4vcnVu dGVzdCBdOyB0aGVuCgltYWtlIC1rIGNoZWNrIDI+JjEgfCB0ZWUgLWEgJFNSQ0RJUi9idWlsZC5s b2cKZWxzZQoJZWNobyAiRGVqYWdudSBub3QgaW5zdGFsbGVkLCBubyBzZWxmdGVzdHMgaGF2ZSBi ZWVuIHJ1bi4iID4kU1JDRElSL2J1aWxkLmxvZwpmaQokU1JDRElSL2NvbnRyaWIvd2Fybl9zdW1t YXJ5IDwkU1JDRElSL2J1aWxkLmxvZyA+JFNSQ0RJUi93YXJuLnN1bW1hcnkKJFNSQ0RJUi9jb250 cmliL3Rlc3Rfc3VtbWFyeSAtaSAkU1JDRElSL3dhcm4uc3VtbWFyeSBcCgk+ICRTUkNESVIvY2hl Y2suc3VtbWFyeQoKJWluc3RhbGwKU1JDRElSPSIkUFdEIgpybSAtcmYgJFJQTV9CVUlMRF9ST09U CmNkICV7T0JKRElSfQoKZXhwb3J0IFBBVEg9JFBBVEg6L3NiaW46L3Vzci9zYmluCgptYWtlIGlu c3RhbGwgXAoJcHJlZml4PSRSUE1fQlVJTERfUk9PVC91c3IgXAoJTUFLRUlORk89Im1ha2VpbmZv IC0tbm8tc3BsaXQiCgpsbiAtc2YgZ2NjICRSUE1fQlVJTERfUk9PVC91c3IvYmluL2NjCmxuIC1z ZiBnNzcgJFJQTV9CVUlMRF9ST09UL3Vzci9iaW4vZjc3CgpsbiAtc2YgZzc3LjEgJFJQTV9CVUlM RF9ST09UL3Vzci9tYW4vbWFuMS9mNzcuMQpsbiAtc2YgY2NjcC4xICRSUE1fQlVJTERfUk9PVC91 c3IvbWFuL21hbjEvY3BwLjEKCmd6aXAgLW4gLTlmICRSUE1fQlVJTERfUk9PVC91c3IvaW5mby8q LmluZm8qIAoKJWNsZWFuCnJtIC1yZiAkUlBNX0JVSUxEX1JPT1QKCiVwb3N0Ci9zYmluL2luc3Rh bGwtaW5mbyAtLWluZm8tZGlyPS91c3IvaW5mbyAvdXNyL2luZm8vZ2NjLmluZm8uZ3oKCiVwb3N0 IC1uIGNwcAovc2Jpbi9pbnN0YWxsLWluZm8gLS1pbmZvLWRpcj0vdXNyL2luZm8gL3Vzci9pbmZv L2NwcC5pbmZvLmd6CgolcG9zdCBnNzcKL3NiaW4vaW5zdGFsbC1pbmZvIC0taW5mby1kaXI9L3Vz ci9pbmZvIC91c3IvaW5mby9nNzcuaW5mby5negoKJXByZXVuCmlmIFsgJDEgPSAwIF07IHRoZW4K ICAgL3NiaW4vaW5zdGFsbC1pbmZvIC0tZGVsZXRlIC0taW5mby1kaXI9L3Vzci9pbmZvIC91c3Iv aW5mby9nY2MuaW5mby5negpmaQoKJXByZXVuIC1uIGNwcAppZiBbICQxID0gMCBdOyB0aGVuCiAg IC9zYmluL2luc3RhbGwtaW5mbyAtLWRlbGV0ZSAtLWluZm8tZGlyPS91c3IvaW5mbyAvdXNyL2lu Zm8vY3BwLmluZm8uZ3oKZmkKCiVwcmV1biBnNzcKaWYgWyAkMSA9IDAgXTsgdGhlbgogICAvc2Jp bi9pbnN0YWxsLWluZm8gLS1kZWxldGUgLS1pbmZvLWRpcj0vdXNyL2luZm8gL3Vzci9pbmZvL2c3 Ny5pbmZvLmd6CmZpCgolcG9zdCAtbiBsaWJzdGRjKysgLXAgL3NiaW4vbGRjb25maWcKCiVwb3N0 dW4gLW4gbGlic3RkYysrIC1wIC9zYmluL2xkY29uZmlnCgolZmlsZXMKJWRlZmF0dHIoLSxyb290 LHJvb3QpCiVkb2MgUkVBRE1FKiBDT1BZSU5HIENPUFlJTkcuTElCIGNoZWNrLnN1bW1hcnkgd2Fy bi5zdW1tYXJ5IGJ1aWxkLmxvZwolZGlyIC91c3IvbGliL2djYy1saWIKJWRpciAvdXNyL2xpYi9n Y2MtbGliLyV7dGFyZ2V0X2FsaWFzfQolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxp YXN9LyoKJWRpciAvdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2luY2x1ZGUKJWlm YXJjaCBhbHBoYQolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovaWVlZQol ZW5kaWYKJWlmYXJjaCBwcGMKJWRpciAvdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8q L25vZgolZW5kaWYKCi91c3IvYmluLyV7dGFyZ2V0X2FsaWFzfS1nY2MKL3Vzci9iaW4vZ2Nvdgov dXNyL2Jpbi9wcm90b2l6ZQovdXNyL2Jpbi91bnByb3RvaXplCi91c3IvYmluL2djYwovdXNyL2Jp bi9jYwovdXNyL2luZm8vZ2NjKgovdXNyL21hbi9tYW4xL2djYy4xCi91c3IvJXt0YXJnZXRfYWxp YXN9Ci91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovU1lTQ0FMTFMuYy5YCi91c3Iv bGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovY2MxCi91c3IvbGliL2djYy1saWIvJXt0YXJn ZXRfYWxpYXN9LyovY29sbGVjdDIKL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9s aWJnY2MuYQolaWZhcmNoIGFscGhhIHBwYwovdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFz fS8qLyovbGliZ2NjLmEKJWVuZGlmCiVpZm5hcmNoIGFscGhhCi91c3IvbGliL2djYy1saWIvJXt0 YXJnZXRfYWxpYXN9LyovKmNydCoubwolZW5kaWYKL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9h bGlhc30vKi9pbmNsdWRlL1JFQURNRQovdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8q L2luY2x1ZGUvZmxvYXQuaAovdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2luY2x1 ZGUvaXNvNjQ2LmgKL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9pbmNsdWRlL2xp bWl0cy5oCi91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVkZS9wcm90by5o Ci91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVkZS9zdGRhcmcuaAovdXNy L2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2luY2x1ZGUvc3RkYm9vbC5oCi91c3IvbGli L2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVkZS9zdGRkZWYuaAovdXNyL2xpYi9nY2Mt bGliLyV7dGFyZ2V0X2FsaWFzfS8qL2luY2x1ZGUvc3lzbGltaXRzLmgKL3Vzci9saWIvZ2NjLWxp Yi8le3RhcmdldF9hbGlhc30vKi9pbmNsdWRlL3ZhLSouaAovdXNyL2xpYi9nY2MtbGliLyV7dGFy Z2V0X2FsaWFzfS8qL2luY2x1ZGUvdmFyYXJncy5oCiVpZmFyY2ggcHBjCi91c3IvbGliL2djYy1s aWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVkZS8qLWFzbS5oCiVlbmRpZgoKCiVmaWxlcyAtbiBj cHAKJWRlZmF0dHIoLSxyb290LHJvb3QpCiVkaXIgL3Vzci9saWIvZ2NjLWxpYgolZGlyIC91c3Iv bGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9CiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3Rhcmdl dF9hbGlhc30vKgolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVk ZQolaWZhcmNoIGFscGhhCiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9p ZWVlCiVlbmRpZgolaWZhcmNoIHBwYwolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxp YXN9Lyovbm9mCiVlbmRpZgoKL2xpYi9jcHAKL3Vzci9iaW4vY3BwCi91c3IvaW5mby9jcHAqCi91 c3IvbWFuL21hbjEvY3BwLjEKL3Vzci9tYW4vbWFuMS9jY2NwLjEKL3Vzci9saWIvZ2NjLWxpYi8l e3RhcmdldF9hbGlhc30vKi9jcHAKL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9z cGVjcwoKCiVmaWxlcyBjKysKJWRlZmF0dHIoLSxyb290LHJvb3QpCiVkaXIgL3Vzci9saWIvZ2Nj LWxpYgolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9CiVkaXIgL3Vzci9saWIv Z2NjLWxpYi8le3RhcmdldF9hbGlhc30vKgolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRf YWxpYXN9LyovaW5jbHVkZQolaWZhcmNoIGFscGhhCiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3Rh cmdldF9hbGlhc30vKi9pZWVlCiVlbmRpZgolaWZhcmNoIHBwYwolZGlyIC91c3IvbGliL2djYy1s aWIvJXt0YXJnZXRfYWxpYXN9Lyovbm9mCiVlbmRpZgoKL3Vzci9iaW4vZysrCi91c3IvYmluL2Mr KwovdXNyL2Jpbi9jKytmaWx0Ci91c3IvbWFuL21hbjEvZysrLjEKL3Vzci9pbmNsdWRlL2crKyoK L3Vzci9saWIvbGlic3RkYysrKi5hCi91c3IvbGliL2xpYnN0ZGMrKyouYS4qCiVpZmFyY2ggYWxw aGEgcHBjCi91c3IvbGliLyovbGlic3RkYysrKi5hCi91c3IvbGliLyovbGlic3RkYysrKi5hLioK JWVuZGlmCi91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovY2MxcGx1cwovdXNyL2xp Yi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2xpYnN0ZGMqCiVpZmFyY2ggYWxwaGEgcHBjCi91 c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovKi9saWJzdGRjKgolZW5kaWYKL3Vzci9s aWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9pbmNsdWRlL2V4Y2VwdGlvbgovdXNyL2xpYi9n Y2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2luY2x1ZGUvbmV3Ci91c3IvbGliL2djYy1saWIvJXt0 YXJnZXRfYWxpYXN9LyovaW5jbHVkZS90eXBlaW5mbwovdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0 X2FsaWFzfS8qL2luY2x1ZGUvbmV3LmgKCgolZmlsZXMgb2JqYwolZGVmYXR0cigtLHJvb3Qscm9v dCkKJWRpciAvdXNyL2xpYi9nY2MtbGliCiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9h bGlhc30KJWRpciAvdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qCiVkaXIgL3Vzci9s aWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9pbmNsdWRlCiVpZmFyY2ggYWxwaGEKJWRpciAv dXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2llZWUKJWVuZGlmCiVpZmFyY2ggcHBj CiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9ub2YKJWVuZGlmCgovdXNy L2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2NjMW9iagovdXNyL2xpYi9nY2MtbGliLyV7 dGFyZ2V0X2FsaWFzfS8qL2xpYm9iamMuYQovdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFz fS8qL2luY2x1ZGUvb2JqYwoKCiVmaWxlcyBnNzcKJWRlZmF0dHIoLSxyb290LHJvb3QpCiVkaXIg L3Vzci9saWIvZ2NjLWxpYgolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9CiVk aXIgL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKgolZGlyIC91c3IvbGliL2djYy1s aWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVkZQolaWZhcmNoIGFscGhhCiVkaXIgL3Vzci9saWIv Z2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9pZWVlCiVlbmRpZgolaWZhcmNoIHBwYwolZGlyIC91 c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9Lyovbm9mCiVlbmRpZgoKL3Vzci9iaW4vZzc3 Ci91c3IvYmluL2Y3NwovdXNyL2luZm8vZzc3KgovdXNyL21hbi9tYW4xL2c3Ny4xCi91c3IvbWFu L21hbjEvZjc3LjEKL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9mNzcxCi91c3Iv bGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovbGliZzJjLmEKJWlmYXJjaCBhbHBoYSBwcGMK L3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi8qL2xpYmcyYy5hCiVlbmRpZgovdXNy L2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2luY2x1ZGUvZzJjLmgKCgolZmlsZXMgY2hp bGwKJWRlZmF0dHIoLSxyb290LHJvb3QpCiVkaXIgL3Vzci9saWIvZ2NjLWxpYgolZGlyIC91c3Iv bGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9CiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3Rhcmdl dF9hbGlhc30vKgolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVk ZQolaWZhcmNoIGFscGhhCiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9p ZWVlCiVlbmRpZgolaWZhcmNoIHBwYwolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxp YXN9Lyovbm9mCiVlbmRpZgoKL3Vzci9iaW4vY2hpbGwKL3Vzci9saWIvZ2NjLWxpYi8le3Rhcmdl dF9hbGlhc30vKi9jYzFjaGlsbAovdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2No aWxscnQwLm8KL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9saWJjaGlsbC5hCiVp ZmFyY2ggYWxwaGEgcHBjCi91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovKi9jaGls bHJ0MC5vCi91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovKi9saWJjaGlsbC5hCiVl bmRpZgoKCiVmaWxlcyBqYXZhCiVkZWZhdHRyKC0scm9vdCxyb290KQolZGlyIC91c3IvbGliL2dj Yy1saWIKJWRpciAvdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfQolZGlyIC91c3IvbGli L2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyoKJWRpciAvdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0 X2FsaWFzfS8qL2luY2x1ZGUKJWlmYXJjaCBhbHBoYQolZGlyIC91c3IvbGliL2djYy1saWIvJXt0 YXJnZXRfYWxpYXN9LyovaWVlZQolZW5kaWYKJWlmYXJjaCBwcGMKJWRpciAvdXNyL2xpYi9nY2Mt bGliLyV7dGFyZ2V0X2FsaWFzfS8qL25vZgolZW5kaWYKCi91c3IvYmluL2djagovdXNyL2Jpbi9n Y2poCi91c3IvYmluL2pjZi1kdW1wCi91c3IvYmluL2p2LXNjYW4KL3Vzci9saWIvZ2NjLWxpYi8l e3RhcmdldF9hbGlhc30vKi9qYzEKL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9q dmdlbm1haW4KCgolZmlsZXMgLW4gbGlic3RkYysrCiVkZWZhdHRyKC0scm9vdCxyb290KQolaWZh cmNoIGFscGhhCiVkaXIgL3Vzci9saWIvaWVlZQolZW5kaWYKJWlmYXJjaCBwcGMKJWRpciAvdXNy L2xpYi9ub2YKJWVuZGlmCgovdXNyL2xpYi9saWJzdGRjKysqLnNvCi91c3IvbGliL2xpYnN0ZGMr Kyouc28uKgolaWZhcmNoIGFscGhhIHBwYwovdXNyL2xpYi8qL2xpYnN0ZGMrKyouc28KL3Vzci9s aWIvKi9saWJzdGRjKysqLnNvLioKJWVuZGlmCgoKJWNoYW5nZWxvZwoqIEZyaSBKdWwgMTYgMTk5 OSBGcmFueiBTaXJsIDxGcmFuei5TaXJsLWtlcm5lbEBsYXV0ZXJiYWNoLmNvbT4KICAtIG92ZXJo YXVsZWQgdGhlIFJILTYuMCBzcGVjIChkb25lIGJ5IENyaXN0aWFuIEdhZnRvbiA8Z2FmdG9uQHJl ZGhhdC5jb20+KQogICAgdG8gZml0IGdjYy0yLjk1Cg== --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD-- From gcc-return-8660-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 11:35:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18034 invoked by alias); 1 Aug 1999 11:35:09 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18027 invoked from network); 1 Aug 1999 11:35:04 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 1 Aug 1999 11:35:04 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id NAA00995; Sun, 1 Aug 1999 13:33:01 +0200 Message-ID: <37A4306D.EE9ECD13@moene.indiv.nluug.nl> Date: Sun, 01 Aug 1999 13:33:01 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: Robert Lipe CC: scherrey@proteus-tech.com, egcs mailing list Subject: Re: Wherefore art thou 2.95 Announcement? References: <37A3945D.E4F68BD5@switchco.com> <19990731190842.R14659@rjlhome.sco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Lipe wrote: > Benjamin Scherrey wrote: > > Slashdot has announced that gcc 2.95 is released but I missed any > > such announcement here. > The announcement went to the egcs-announce list this a.m. > http://egcs.cygnus.com/ml/gcc-announce/1999/msg00008.html And indeed the ever-awake slashdot guys picked it up in Internet time. One of the more entertaining reactions: I'm having problems compiling it for HP-UX 10.20. Any ideas? (I haven't actually finished downloading it yet, but I just know I'm gonna have problems with this crappy OS ;-) I'm afraid Jeff - as the PA port maintainer - will "not be amused" :-) > The release is indeed available now at an archive near you. > > "You missed the starting gun/No one told you when to run..." [ Yeah - see if we can spot the over-35's in the audience ] I would opt for the more classical: "Alea Iacta Est". We've crossed this Rubicon - egcs now *is* GCC and we have to deal with the politics this ensues - which is not the same as having to put up with everything RMS thinks up. Free Software is an empty slogan without Free Compilers - it's our responsibility to provide them, in the best possible way. -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-8661-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 13:40:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13376 invoked by alias); 1 Aug 1999 13:40:39 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13368 invoked from network); 1 Aug 1999 13:40:35 -0000 Received: from cable-modem113.m2.kabelnet.net (HELO phobos.hvrlab.dhs.org) (root@195.202.132.113) by egcs.cygnus.com with SMTP; 1 Aug 1999 13:40:35 -0000 Received: from phoenix.twisted.hvrlab.dhs.org (phoenix.twisted.hvrlab.dhs.org [10.51.1.3]) by phobos.hvrlab.dhs.org (8.9.3/8.9.3) with ESMTP id PAA13575 for ; Sun, 1 Aug 1999 15:38:25 +0200 Date: Sun, 1 Aug 1999 15:38:24 +0200 (CEST) From: Herbert Valerio Riedel X-Sender: hvr@phoenix.twisted.hvrlab.dhs.org To: gcc@gcc.gnu.org Subject: build/installed successfully on linux/alpha Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII done on redhat6.0/axp (with installed binutils-2.9.1.0.23) [root@phoenix gcc-2.95]# ./config.guess alphapca56-unknown-linux-gnu [root@phoenix /root]# gcc -v Reading specs from /usr/local/lib/gcc-lib/alphapca56-unknown-linux-gnu/2.95/specs gcc version 2.95 19990728 (release) -- "First they ignore you, then they laugh at you, then they fight you, then you win." -- Gandhi (?) From gcc-return-8662-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 14:39:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15868 invoked by alias); 1 Aug 1999 14:39:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15861 invoked from network); 1 Aug 1999 14:39:55 -0000 Received: from dhcp31174138.columbus.rr.com (HELO quasar) (24.31.174.138) by egcs.cygnus.com with SMTP; 1 Aug 1999 14:39:55 -0000 Received: from beer.com (localhost [127.0.0.1]) by quasar (8.9.3/8.9.3) with ESMTP id KAA02548 for ; Sun, 1 Aug 1999 10:46:37 -0400 (EDT) Message-ID: <37A45DCD.96088777@beer.com> Date: Sun, 01 Aug 1999 10:46:37 -0400 From: Jon Schlegel Reply-To: Jon Schlegel Organization: None X-Mailer: Mozilla 4.51 [en] (X11; I; OpenBSD 2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Sucessful build on OpenBSD 2.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit schlegel@quasar:temp# ./gcc-2.95/config.guess i386-unknown-openbsd2.5 From gcc-return-8663-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 15:23:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18517 invoked by alias); 1 Aug 1999 15:22:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18510 invoked from network); 1 Aug 1999 15:22:39 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 1 Aug 1999 15:22:39 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id JAA29731; Sun, 1 Aug 1999 09:19:58 -0600 X-Mailer: exmh version 2.0.2 To: scherrey@proteus-tech.com cc: egcs mailing list Subject: Re: Wherefore art thou 2.95 Announcement? Reply-To: law@cygnus.com In-reply-to: Your message of Sat, 31 Jul 1999 19:27:09 CDT. <37A3945D.E4F68BD5@switchco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Aug 1999 09:19:58 -0600 Message-ID: <29728.933520798@upchuck.cygnus.com> From: Jeffrey A Law In message <37A3945D.E4F68BD5@switchco.com>you write: > > Slashdot has announced that gcc 2.95 is released but I missed any > such announcement here. Last I read, we were waiting for some final > OK's from RMS. I hope that's not always going to be a future > requirement. So is this thing released now or what?!?!? It is unfortunate that /. & freshmeat do not wait for the official announcements. Typically we put the release on the server, then give the mirrors 24-72hrs to pick up the new release before we make the official announcement. Part of the egcs/gcc merger means that we have to play more nicely with RMS, so these things are going to happen from time to time. If you're unhappy about that, you should indicate your unhappiness to RMS. jeff From gcc-return-8664-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 15:24:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19171 invoked by alias); 1 Aug 1999 15:24:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19153 invoked from network); 1 Aug 1999 15:24:23 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 1 Aug 1999 15:24:23 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id JAA29753; Sun, 1 Aug 1999 09:21:43 -0600 X-Mailer: exmh version 2.0.2 To: "Robert C. Paulsen, Jr." cc: gcc@gcc.gnu.org Subject: Re: gcc 2.95 build success, with minor problem Reply-To: law@cygnus.com In-reply-to: Your message of Sat, 31 Jul 1999 20:15:04 CDT. <37A39F98.537E02D5@texas.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Aug 1999 09:21:43 -0600 Message-ID: <29750.933520903@upchuck.cygnus.com> From: Jeffrey A Law In message <37A39F98.537E02D5@texas.net>you write: > Successful build on i586-pc-linux-gnu > > But, I had to specify the host type: > > ../gcc-2.95/configure --host=i586-pc-linux-gnu > > Without doing so, configure reports.. > > "config.guess failed to determine the host type" > > Note that egcs-1.1.2 has the same problem today, but it did not > have this problem a couple of months ago when I first installed it. If config.guess can not determine your host type, then something is very very wrong. You should investigate why config.guess did not work on your system (it's just a big ugly shell script, so it's not terrible to debug). Lots of things can go wrong if config.guess does not properly determine what kind of host you have. So it is in your best interest to investigate and get this problem fixed. jeff From gcc-return-8665-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 15:31:40 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20431 invoked by alias); 1 Aug 1999 15:31:39 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20424 invoked from network); 1 Aug 1999 15:31:38 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 1 Aug 1999 15:31:38 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id JAA29798; Sun, 1 Aug 1999 09:28:52 -0600 X-Mailer: exmh version 2.0.2 To: Toon Moene cc: Robert Lipe , scherrey@proteus-tech.com, egcs mailing list Subject: Re: Wherefore art thou 2.95 Announcement? Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 01 Aug 1999 13:33:01 +0200. <37A4306D.EE9ECD13@moene.indiv.nluug.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Aug 1999 09:28:51 -0600 Message-ID: <29795.933521331@upchuck.cygnus.com> From: Jeffrey A Law In message <37A4306D.EE9ECD13@moene.indiv.nluug.nl>you write: > > The announcement went to the egcs-announce list this a.m. > > http://egcs.cygnus.com/ml/gcc-announce/1999/msg00008.html > > And indeed the ever-awake slashdot guys picked it up in Internet time. The /. folk don't wait for release announcements (unfortunately); in the past they would "break the news" within 24hrs after we put the tarballs up for ftp, but for reasons unknown they didn't catch this release for about 48hrs. Not that I'm complaining -- it gave our mirrors more time to pick up the tarballs before the thundering herd melted the network. Having the release on gnu.org will also mitigate the thundering herd problem. > One of the more entertaining reactions: > > > I'm having problems compiling it for HP-UX 10.20. Any ideas? > > (I haven't actually finished downloading it yet, but I just know I'm > gonna have problems with this crappy OS ;-) > > > I'm afraid Jeff - as the PA port maintainer - will "not be amused" :-) :-) I read it, but I'm not overly worried about it since obviously this guy didn't read the install documentation. hpux has "just worked" since about 1993 or so if you follow the instructions :-) > > "You missed the starting gun/No one told you when to run..." > > [ Yeah - see if we can spot the over-35's in the audience ] Ha! You don't have to be over-35 to catch that one. > We've crossed this Rubicon - egcs now *is* GCC and we have to deal with > the politics this ensues - which is not the same as having to put up > with everything RMS thinks up. Correct. > Free Software is an empty slogan without Free Compilers - it's our > responsibility to provide them, in the best possible way. Correct. Thanks, jeff From gcc-return-8666-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 19:44:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4982 invoked by alias); 1 Aug 1999 19:44:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4975 invoked from network); 1 Aug 1999 19:44:39 -0000 Received: from mail.switchco.com (root@199.190.187.52) by egcs.cygnus.com with SMTP; 1 Aug 1999 19:44:39 -0000 Received: from switchco.com (proteus.swithcho.com [199.190.187.45]) by mail.switchco.com (8.8.0/8.6.12) with ESMTP id OAA18501; Sun, 1 Aug 1999 14:39:58 -0400 Message-ID: <37A4B06F.9652339D@switchco.com> Date: Sun, 01 Aug 1999 15:39:11 -0500 From: Benjamin Scherrey Reply-To: scherrey@proteus-tech.com Organization: Proteus Technologies, Inc. X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: law@cygnus.com CC: egcs mailing list Subject: Re: Wherefore art thou 2.95 Announcement? References: <29728.933520798@upchuck.cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeffrey A Law wrote: > > Part of the egcs/gcc merger means that we have to play more nicely with RMS, > so these things are going to happen from time to time. If you're unhappy about > that, you should indicate your unhappiness to RMS. I'm not specifically unhappy about it as much as I am concerned. If the required co-ordination with RMS is strictly due to the merger activities then I understand and have no problem with it. If, however, it is an indication of future things to come and describes what will soon be business as usual then I'm willing to start taking bets on when the next source tree split takes place and "Son of EGCS" comes into being. The egcs project was successful, in large part, due to the autonomy of the development group and the good sense of its main personnel (like Jeff for instance). Had it not been for these efforts, progress on the gcc compiler suite would have (or rather, did!) come to a standstill I believe. The whole "Cathedral vs. Bazaar" thing comes into play here in a big way. Otherwise, some one please tell me what the heck was the benefit of becoming the "official gcc" again?!?!? Just a concern from some guy who doesn't know the inside story. Tell me if I'm wrong. Ben Scherrey From gcc-return-8667-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 21:29:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11104 invoked by alias); 1 Aug 1999 21:29:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11097 invoked from network); 1 Aug 1999 21:29:15 -0000 Received: from pluto.rigroup.com (204.233.70.9) by egcs.cygnus.com with SMTP; 1 Aug 1999 21:29:15 -0000 Received: from oemcomputer ([208.252.202.61]) by pluto.rigroup.com (Netscape Messaging Server 3.6) with SMTP id AAA958A for ; Sun, 1 Aug 1999 16:19:58 -0500 Message-Id: <3.0.6.32.19990801142449.00835470@mail.ofe.org> X-Sender: dstarner98@mail.ofe.org X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Sun, 01 Aug 1999 14:24:49 -0700 To: egcs mailing list From: David Starner Subject: Re: Wherefore art thou 2.95 Announcement? In-Reply-To: <37A4B06F.9652339D@switchco.com> References: <29728.933520798@upchuck.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 03:39 PM 8/1/99 -0500, Benjamin Scherrey wrote: >The egcs project was successful, in large part, due to the >autonomy of the development group and the good sense of its main >personnel (like Jeff for instance). The same development group is still there. The GCC steering commitee is the EGCS steering committee. >Had it not been for these efforts, >progress on the gcc compiler suite would have (or rather, did!) come >to a standstill I believe. It didn't come to a standstill, it merely slowed way down. The fact that many good developers were drawn off for the more developer friendly egcs project couldn't have helped. >The whole "Cathedral vs. Bazaar" thing >comes into play here in a big way. There is no plans to make the way GCC is developed any different from the way egcs was. >Otherwise, some one please tell me >what the heck was the benefit of becoming the "official gcc" >again?!?!? No more problems with the glibc issue. No more redudant CVS servers, mailing lists, ect. The frontend people (f77 and Pascal) can stop supporting two releases, and the Ada people will start supporting the most recent version of GCC instead 2.8.1. Distributors and users no longer have to worry about supporting gcc 2.8.1 and egcs. -- David Starner - dstarner98@aasaa.ofe.org (alternately dvdeug@hotmail.com) "I would weep, but my tears have been stolen; I would shout, but my voice has been taken. Thus, I write." - Tragic Poet From gcc-return-8668-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 22:12:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14599 invoked by alias); 1 Aug 1999 22:12:22 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14592 invoked from network); 1 Aug 1999 22:12:18 -0000 Received: from zanak-2-67.mdm.mke.execpc.com (HELO mail.execpc.com) (qmailr@169.207.73.67) by egcs.cygnus.com with SMTP; 1 Aug 1999 22:12:18 -0000 Received: (qmail 656 invoked by uid 1000); 1 Aug 1999 22:09:11 -0000 Date: Sun, 1 Aug 1999 17:09:11 -0500 From: "A. P. Garcia" To: egcs@egcs.cygnus.com Subject: off-topic: Re: Wherefore art thou 2.95 Announcement? Message-ID: <19990801170911.A610@execpc.com> References: <37A3945D.E4F68BD5@switchco.com> <19990731190842.R14659@rjlhome.sco.com> <37A4306D.EE9ECD13@moene.indiv.nluug.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <37A4306D.EE9ECD13@moene.indiv.nluug.nl>; from Toon Moene on Sun, Aug 01, 1999 at 01:33:01PM +0200 Hackers familiar with Pink Floyd are everywhere. Ones familiar with Caesar and Pompey - that is a different matter, no? On Sun, Aug 01, 1999 at 01:33:01PM +0200, Toon Moene wrote: > > "You missed the starting gun/No one told you when to run..." > > [ Yeah - see if we can spot the over-35's in the audience ] > > I would opt for the more classical: > > "Alea Iacta Est". > > We've crossed this Rubicon - egcs now *is* GCC and we have to deal with > the politics this ensues - which is not the same as having to put up > with everything RMS thinks up. From gcc-return-8669-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 23:18:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21568 invoked by alias); 1 Aug 1999 23:18:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21561 invoked from network); 1 Aug 1999 23:18:24 -0000 Received: from eclipse.pacifier.com (199.2.117.78) by egcs.cygnus.com with SMTP; 1 Aug 1999 23:18:24 -0000 Received: from pacifier.com (bruceq@pacifier.com [199.2.117.161]) by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id QAA27186 for ; Sun, 1 Aug 1999 16:16:51 -0700 (PDT) Date: Sun, 1 Aug 1999 16:16:55 -0700 (PDT) From: Bruce Q Hammond To: egcs@egcs.cygnus.com Subject: Contribution to egcs In-Reply-To: <199908011805.LAA12508@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I am interested in beoming a contributor to the egcs project. My primary interest is in improving compile times and link times for debugging builds of large C++ apps (e.g. > 4MB executatable when striped) My current app swells from 5 MB to 130MB for debug and takes forever to link on a machine with 256MB of RAM. Compile times for non-optimized builds is also unaceptable for my purposes. My first step would be to try and understand what is happening now and learn about the existing designs and the build process. I am working with the gcc for BeOSx86 -- should I get the distrbution directly from them Be, Inc? What mailing-list should I use for general discussion of the above issues and what might be done about them? Who (or what list) should I contact for questions regarding configuration/make to build gcc? Best, --BQ Bruce Q. Hammond Gobe Software From gcc-return-8670-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 23:22:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22567 invoked by alias); 1 Aug 1999 23:22:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22552 invoked from network); 1 Aug 1999 23:22:49 -0000 Received: from morannon.bfr.co.il (HELO buster.bfr.co.il) (root@192.116.142.129) by egcs.cygnus.com with SMTP; 1 Aug 1999 23:22:49 -0000 Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id CAA06836 for ; Mon, 2 Aug 1999 02:21:24 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.9.3/8.8.5) id XAA01479; Sun, 1 Aug 1999 23:04:33 +0300 To: egcs@egcs.cygnus.com Subject: gcc-2.95 build FAILED! - RedHat Linux/Alpha 5.2 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: abel@bfr.co.il (Alexander L. Belikoff) Date: 01 Aug 1999 23:04:32 +0300 Message-ID: Lines: 59 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Yep - justs failed to build on: - Alpha dp264 (dual CPU) - RedHat 5.2 - egcs 1.1.2, binutils 2.9.1.0.15-1 This is pretty painful and surprising, considering that egcs-19990712 built just fine. Anybody cares to fix that or just "stick to RedHat 6.0, you pathetic looser!" ;-) We are slowly migrating on our Alphas from RedHat 4.2 to RedHat 5.2. 6.0 is out of question - there are too many complaints about general stability and speed. On RedHat 5.2 the situation with the compilers is the following: 1. Egcs 1.0.3 (supplied by RedHat) - gives ICE on certain optimization flags (I reported it quite a while ago). 2. Egcs 1.1.2 (built manually) - has the infamous memcpy bug. 3. Gcc 2.95 - fails to build. This doesn't look very optimistic, does it? ;-) Anyway, here goes the make log: if [ x"no" = xyes ]; then \ /bb/home/abel/eb/gcc/xgcc -B/bb/home/abel/eb/gcc/ -B/usr/local/gcc-2.95/alphaev6-unknown-linux-gnu/bin/ -c -g -O2 -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates -mieee -I../../../../gcc-2.95/libstdc++ -I../../../../gcc-2.95/libstdc++/stl -I../libio -I../../../../gcc-2.95/libstdc++/../libio -nostdinc++ -D_IO_MTSAFE_IO -DF \ `for N in MAIN ADDCC ADDCF ADDFC SUBCC SUBCF SUBFC MULCC MULCF MULFC DIVCC DIVCF DIVFC PLUS MINUS EQCC EQCF EQFC NECC NECF NEFC ABS ARG POLAR CONJ NORM COS COSH EXP LOG POWCC POWCF POWCI POWFC SIN SINH SQRT; do echo " -D${N}"; done` \ ../../../../gcc-2.95/libstdc++/cinst.cc -o pic/fcomplex.o; \ else true ; fi /bb/home/abel/eb/gcc/xgcc -B/bb/home/abel/eb/gcc/ -B/usr/local/gcc-2.95/alphaev6-unknown-linux-gnu/bin/ -c -g -O2 -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates -mieee -I../../../../gcc-2.95/libstdc++ -I../../../../gcc-2.95/libstdc++/stl -I../libio -I../../../../gcc-2.95/libstdc++/../libio -nostdinc++ -D_IO_MTSAFE_IO -DF `for N in MAIN ADDCC ADDCF ADDFC SUBCC SUBCF SUBFC MULCC MULCF MULFC DIVCC DIVCF DIVFC PLUS MINUS EQCC EQCF EQFC NECC NECF NEFC ABS ARG POLAR CONJ NORM COS COSH EXP LOG POWCC POWCF POWCI POWFC SIN SINH SQRT; do echo " -D${N}"; done` \ ../../../../gcc-2.95/libstdc++/cinst.cc -o fcomplex.o /tmp/cc2jzCeM.s: Assembler messages: /tmp/cc2jzCeM.s:3711: Error: unknown opcode `sqrttsu' /tmp/cc2jzCeM.s:3781: Error: unknown opcode `sqrttsu' make[4]: *** [bigstmp-complx] Error 1 make[4]: Leaving directory `/bb/home/abel/eb/alphaev6-unknown-linux-gnu/ieee/libstdc++' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/bb/home/abel/eb/alphaev6-unknown-linux-gnu/libstdc++' make[2]: *** [multi-all] Error 2 make[2]: Leaving directory `/bb/home/abel/eb/alphaev6-unknown-linux-gnu/libstdc++' make[1]: *** [all-target-libstdc++] Error 2 make[1]: Leaving directory `/bb/home/abel/eb' make: *** [bootstrap] Error 2 PS. In case you are going to suggest upgrading binutils, could you please also explain what exactly was fine with the latter package 3 weeks ago, that got horribly wrong now?.. Thanks in advance, -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@vallinor4.com, abel@bfr.co.il From gcc-return-8671-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 01 23:56:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26009 invoked by alias); 1 Aug 1999 23:56:03 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25998 invoked from network); 1 Aug 1999 23:56:02 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 1 Aug 1999 23:56:02 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id RAA30703; Sun, 1 Aug 1999 17:53:10 -0600 X-Mailer: exmh version 2.0.2 To: abel@bfr.co.il (Alexander L. Belikoff) cc: egcs@egcs.cygnus.com Subject: Re: gcc-2.95 build FAILED! - RedHat Linux/Alpha 5.2 Reply-To: law@cygnus.com In-reply-to: Your message of 01 Aug 1999 23:04:32 +0300. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Aug 1999 17:53:10 -0600 Message-ID: <30700.933551590@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > /tmp/cc2jzCeM.s:3711: Error: unknown opcode `sqrttsu' > /tmp/cc2jzCeM.s:3781: Error: unknown opcode `sqrttsu' Your assembler is out of date. Get a newer one. jeff From gcc-return-8672-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 00:21:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28068 invoked by alias); 2 Aug 1999 00:21:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28058 invoked from network); 2 Aug 1999 00:21:30 -0000 Received: from morannon.bfr.co.il (HELO buster.bfr.co.il) (root@192.116.142.129) by egcs.cygnus.com with SMTP; 2 Aug 1999 00:21:30 -0000 Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id DAA07714 for ; Mon, 2 Aug 1999 03:20:03 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.9.3/8.8.5) id AAA01575; Mon, 2 Aug 1999 00:03:12 +0300 To: egcs@egcs.cygnus.com Subject: Re: gcc-2.95 build FAILED! - RedHat Linux/Alpha 5.2 References: <30700.933551590@upchuck.cygnus.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: abel@bfr.co.il (Alexander L. Belikoff) Date: 02 Aug 1999 00:03:12 +0300 In-Reply-To: Jeffrey A Law's message of "Sun, 01 Aug 1999 17:53:10 -0600" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Jeffrey A Law writes: > In message you write: > > /tmp/cc2jzCeM.s:3711: Error: unknown opcode `sqrttsu' > > /tmp/cc2jzCeM.s:3781: Error: unknown opcode `sqrttsu' > Your assembler is out of date. Get a newer one. > > jeff But it was good enough three weeks ago, when gcc was in (apparent) deep freeze! Is there any reason for losing backward compatibility in such an abrupt way? Binutils is a major package we are definitely not going to upgrade it unless such an upgrade is critical - we are talking about production systems... This basically rules out *previous* (read, "stable") release of a major Linux distribution... :-( -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@vallinor4.com, abel@bfr.co.il From gcc-return-8673-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 00:33:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29240 invoked by alias); 2 Aug 1999 00:33:05 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29233 invoked from network); 2 Aug 1999 00:33:04 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 2 Aug 1999 00:33:04 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id SAA30802; Sun, 1 Aug 1999 18:30:21 -0600 X-Mailer: exmh version 2.0.2 To: scherrey@proteus-tech.com cc: egcs mailing list Subject: Re: Wherefore art thou 2.95 Announcement? Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 01 Aug 1999 15:39:11 CDT. <37A4B06F.9652339D@switchco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Aug 1999 18:30:21 -0600 Message-ID: <30799.933553821@upchuck.cygnus.com> From: Jeffrey A Law In message <37A4B06F.9652339D@switchco.com>you write: > I'm not specifically unhappy about it as much as I am concerned. It's still worth expressing your concerns to RMS. > If the required co-ordination with RMS is strictly due to the merger > activities then I understand and have no problem with it. If, however, > it is an indication of future things to come and describes what will > soon be business as usual then I'm willing to start taking bets on > when the next source tree split takes place and "Son of EGCS" comes > into being. Some is merger, some is philosophical. Neither necessarily means there will be a split as long as all parties involved stay reasonable. And that's a large part of why we have a steering committee -- to lessen the impact of individual personalities and prejudices and help ensure people try to reason with each other and choose a course that is best for GCC. > comes into play here in a big way. Otherwise, some one please tell me > what the heck was the benefit of becoming the "official gcc" > again?!?!? >From a purely technical standpoint, a single source base from which we all work rather than trying to do merges back and forth, the fortran, pascal, ada, etc folks only have to make their front-ends work with one release at a time (just ask Craig how much work it was to keep g77 working with both the egcs source base and the gcc-2.8 source base). >From a non-technical standpoint, the merger greatly expands our user base and helps gain acceptance into more areas. jeff From gcc-return-8674-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 00:35:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30072 invoked by alias); 2 Aug 1999 00:35:05 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30064 invoked from network); 2 Aug 1999 00:35:03 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 2 Aug 1999 00:35:03 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id SAA30822; Sun, 1 Aug 1999 18:32:17 -0600 X-Mailer: exmh version 2.0.2 To: abel@bfr.co.il (Alexander L. Belikoff) cc: egcs@egcs.cygnus.com Subject: Re: gcc-2.95 build FAILED! - RedHat Linux/Alpha 5.2 Reply-To: law@cygnus.com In-reply-to: Your message of 02 Aug 1999 00:03:12 +0300. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Aug 1999 18:32:17 -0600 Message-ID: <30819.933553937@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > But it was good enough three weeks ago, when gcc was in (apparent) > deep freeze! Is there any reason for losing backward compatibility in > such an abrupt way? Binutils is a major package we are definitely not > going to upgrade it unless such an upgrade is critical - we are > talking about production systems... This basically rules out > *previous* (read, "stable") release of a major Linux distribution... The assembler is broken, plain and simple. Get a newer one. There may be a way to disable those instructions, but I wouldn't know what it is since I do not normally work on alphas, jeff From gcc-return-8675-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 00:37:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30919 invoked by alias); 2 Aug 1999 00:37:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30911 invoked from network); 2 Aug 1999 00:37:44 -0000 Received: from host162.nashville.com (HELO rjlhome.sco.com) (207.65.231.162) by egcs.cygnus.com with SMTP; 2 Aug 1999 00:37:44 -0000 Received: (from robertl@localhost) by rjlhome.sco.com (8.8.8/SCO5) id TAA06184; Sun, 1 Aug 1999 19:35:28 -0500 (CDT) Date: Sun, 1 Aug 1999 19:35:28 -0500 From: Robert Lipe To: Bruce Q Hammond Cc: egcs@egcs.cygnus.com Subject: Re: Contribution to egcs Message-ID: <19990801193528.B6067@rjlhome.sco.com> References: <199908011805.LAA12508@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95us In-Reply-To: ; from Bruce Q Hammond on Sun, Aug 01, 1999 at 04:16:55PM -0700 > I am interested in beoming a contributor to the egcs project. My A trip to http://egcs.cygnus.com (specifically "/contribute.html") is in order. > primary interest is in improving compile times and link times for > debugging builds of large C++ apps (e.g. > 4MB executatable when striped) > My current app swells from 5 MB to 130MB for debug and takes forever to > link on a machine with 256MB of RAM. Compile times for non-optimized > builds is also unaceptable for my purposes. Sounds like a pretty traditional performance problem. Profile it, see where the time is going, and make it spend less time there. If, for example, you see that it's spending 90% of its time doing disk I/O then optimizing the register reload allocator isn't the best plan ever. > My first step would be to try and understand what is happening now and > learn about the existing designs and the build process. I am working with Personally, I'd start by profiling it. Watch the % of times you're spending in user and system mode. Go from there. > the gcc for BeOSx86 -- should I get the distrbution directly from them Be, > Inc? BeOS isn't heavily represented in this group so you may or may not be up against a Be-specific issue. > What mailing-list should I use for general discussion of the above issues > and what might be done about them? Who (or what list) should I contact for > questions regarding configuration/make to build gcc? http://egcs.cygnus.com/lists.html I remember back int he old days when we had to TYPE answers to questions instead of cutting and pasting URLs. :-) RJL From gcc-return-8676-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 01:10:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3975 invoked by alias); 2 Aug 1999 01:10:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3957 invoked from network); 2 Aug 1999 01:10:34 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 2 Aug 1999 01:10:34 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id TAA30957; Sun, 1 Aug 1999 19:07:47 -0600 X-Mailer: exmh version 2.0.2 To: Bruce Q Hammond cc: egcs@egcs.cygnus.com Subject: Re: Contribution to egcs Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 01 Aug 1999 16:16:55 PDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Aug 1999 19:07:47 -0600 Message-ID: <30954.933556067@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > I am interested in beoming a contributor to the egcs project. Great! > My primary interest is in improving compile times and link times for > debugging builds of large C++ apps (e.g. > 4MB executatable when striped) > My current app swells from 5 MB to 130MB for debug and takes forever to > link on a machine with 256MB of RAM. Compile times for non-optimized > builds is also unaceptable for my purposes. First thing to check, are you getting redundant template instantiations (is that the right term C++ folks?). If you are, that might explain why your code is so big. It would also explain some of the huge bloat with your debug symbols. I believe beos uses dwarf2 debug records, right? Then the next step is to make sure you've got a newer assembler :-) New assemblers have the ability to compress some of the EH related tables that have to be built into every C++ module. Even then I suspect the debug symbols are going to be large -- rumor has it the way to fix them is actually in the linker by removing redundant info that can only be found at link time. I'm not a dwarf2 expert, but this is what I've been told and it meshes with my experiences with stabs & HP's debug format, both of which are compressed at link time by removal of redundant information. > What mailing-list should I use for general discussion of the above issues > and what might be done about them? Who (or what list) should I contact for > questions regarding configuration/make to build gcc? You've already got the right list :-) You should also glance at the main web page since it has pointers to stuff like using CVS to check out the development tree, legal issues surrounding patches, coding style stuff, etc etc. jeff From gcc-return-8677-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 02:01:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9441 invoked by alias); 2 Aug 1999 02:01:27 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9434 invoked from network); 2 Aug 1999 02:01:25 -0000 Received: from unknown (HELO dancing-nancy.winnertech.com) (209.236.143.2) by egcs.cygnus.com with SMTP; 2 Aug 1999 02:01:25 -0000 Received: from danielbe3 ([208.252.227.162]) by dancing-nancy.winnertech.com (Netscape Mail Server v2.0) with SMTP id AAA166; Sun, 1 Aug 1999 23:00:36 -0400 From: "Daniel Berlin" To: "Bruce Q Hammond" , Subject: RE: Contribution to egcs Date: Sun, 1 Aug 1999 21:59:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.3100 > Hello, > > I am interested in beoming a contributor to the egcs project. My > primary interest is in improving compile times and link times for > debugging builds of large C++ apps (e.g. > 4MB executatable when > striped) > My current app swells from 5 MB to 130MB for debug and takes forever to > link on a machine with 256MB of RAM. Compile times for non-optimized > builds is also unaceptable for my purposes. > > My first step would be to try and understand what is happening now and > learn about the existing designs and the build process. I am working with > the gcc for BeOSx86 -- should I get the distrbution directly from > them Be, Inc? I'm not sure if the changes were merged with egcs yet, the Be changes seem to have made it into the binutils (and other pieces, as soon as i get some free time, i'll clean up my gdb changes and submit them), so the best place may just be to grab the latest sources from geekgadgets. It should also be on the R4.5 CD. Someone around here might know what version/date the latest GNUPro distribution (99r2 i believe) is close to in the EGCS source tree (minus the cygnus made changes, of course) You are barking up the wrong tree, however. IMHO. I've barked up this one before. What you really need to do is implement compression/removal of redundant DWARF2 info into ld. It's not an easy task. The easiest way to see if it's redundant info that's killing you is to make one file that includes all the source files in your project, and compile/link that. If it's about 95% smaller, your problem is redundant DWARF2 info. HTH, Dan From gcc-return-8678-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 04:01:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22591 invoked by alias); 2 Aug 1999 04:01:10 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22580 invoked from network); 2 Aug 1999 04:01:10 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 2 Aug 1999 04:01:10 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990802035947.IUOR9894.mail.rdc1.md.home.com@home.com> for ; Sun, 1 Aug 1999 20:59:47 -0700 Message-ID: <37A517F4.482366F0@home.com> Date: Mon, 02 Aug 1999 00:00:52 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: egcs@egcs.cygnus.com Subject: Improving C++ error messages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry if this has come up before but does anyone plan on ever improving C++ error messages with complicated templates. For example an error message of: /usr/local/gcc2.95/bin/g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../ -I../util -I../lib/inc -I../popt -g -c aspell.cc ../lib/inc/check.hh: In method `const char region_skipper_iterator<_Rope_const_iterator >,_Rope_const_iterator > >::operator *() const': ../lib/inc/check-t.hh:66: instantiated from `region_skipper_iterator_nv<_Rope_const_iterator >,_Rope_const_iterator > >::operator *() const' ../lib/inc/token-t.hh:16: instantiated from `tok >,_Rope_const_iterator > >,region_skipper_iterator_nv_end<_Rope_const_iterator >,_Rope_const_iterator > > >::operator ++()' ../lib/inc/token.hh:23: instantiated from `tok >,_Rope_const_iterator > >,region_skipper_iterator_nv_end<_Rope_const_iterator >,_Rope_const_iterator > > >::tok(const region_skipper_iterator_nv<_Rope_const_iterator >,_Rope_const_iterator > > &, const region_skipper_iterator_nv_end<_Rope_const_iterator >,_Rope_const_iterator > > &, const SC_Language &)' ../lib/inc/check-t.hh:116: instantiated from `check<_Rope_const_iterator >, _Rope_const_iterator >, AS_DoNothing>(const aspell &, aspell_check_state<_Rope_const_iterator >,_Rope_const_iterator > > &, const AS_DoNothing &)' ../lib/inc/check.hh:172: instantiated from here ../lib/inc/check.hh:53: passing `const _Rope_const_iterator >' as `this' argument of `char _Rope_const_iterator >::operator *()' discards qualifiers make: *** [aspell.o] Error 1 is just a little bit ridicules. I don't know what what would be the best solution to this problem is but for god sakes something needs to be done as wading through what all this means is a rather difficult task. I would like to see a solution where the compile tracks keep tracks of the typedef currently in uses that name instead of the fully expanded one. I am not saying it would be easy but it would go a LONG way in producing much for readable messages. For example _Rope_const_iterator should really be crope::const_iterator Also template parameters which are the defaults should also be eliminated. For example: _Rope_const_iterator should be _Rope_const_iterator What do you think? Also why does gcc only give the line number when giving an error message. A character offset in many cases would be very useful as often something like before '(' is not very useful when there is a parse or syntax error as I have many '(' on one line. I really hope someone will take me seriously. And, before you ask, I do not have the knowledge or time to do it my self. -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-8679-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 04:17:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25321 invoked by alias); 2 Aug 1999 04:17:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25314 invoked from network); 2 Aug 1999 04:17:41 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 2 Aug 1999 04:17:41 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id WAA31301; Sun, 1 Aug 1999 22:14:56 -0600 X-Mailer: exmh version 2.0.2 To: rth@cygnus.com Cc: gcc@gcc.gnu.org Reply-To: law@cygnus.com Subject: New cfg code Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Aug 1999 22:14:56 -0600 Message-ID: <31298.933567296@upchuck.cygnus.com> From: Jeffrey A Law Fun fun fun. Suppose we have something like this before cse2: (insn 75 104 77 (set (reg:SI 25) (reg:SI 27)) 48 {movsi+2} (nil) (expr_list:REG_LABEL (code_label 80 79 81 15 "" [num uses: 2]) (expr_list:REG_EQUAL (label_ref:SI 80) (nil)))) (insn 77 75 78 (set (reg:SI 26) (mem/u:SI (plus:SI (mult:SI (reg:SI 24) (const_int 4 [0x4])) (reg:SI 25)) 0)) 48 {movsi+2} (nil) (nil)) (jump_insn 78 77 79 (parallel[ (set (pc) (reg:SI 26)) (use (label_ref 80)) ] ) 364 {tablejump} (nil) (nil)) (barrier 79 78 80) (code_label 80 79 81 15 "" [num uses: 2]) (jump_insn 81 80 82 (addr_vec:SI[ (barrier) [ ... more insns ... ] end of function Then let's assume that we can determine that reg24 is a constant. And therefore we can determine the precise target of the tablejump in insn 78. CSE deletes insn 78, and emits a fresh new jump to the constant target, then deletes insn 78. Since insn 78 is followed by a BARRIER, delete_insn will *not* delete (code_label 80) or (jump_insn 81). The RTL after this looks like: (insn 75 104 77 (set (reg:SI 25) (reg:SI 27)) 48 {movsi+2} (nil) (expr_list:REG_EQUAL (label_ref:SI 80) (nil))) (insn 77 75 111 (set (reg:SI 26) (label_ref:SI 16)) 48 {movsi+2} (nil) (expr_list:REG_LABEL (code_label 16 10 103 5 "" [num uses: 9]) (expr_list:REG_EQUAL (label_ref:SI 16) (nil)))) (jump_insn 111 77 112 (set (pc) (label_ref 16)) -1 (nil) (nil)) (barrier 112 111 80) (code_label 80 112 81 15 "" [num uses: 1]) (jump_insn 81 80 82 (addr_vec:SI[ (label_ref:SI 16) (label_ref:SI 16) (label_ref:SI 16) (label_ref:SI 16) (label_ref:SI 16) (label_ref:SI 41) (label_ref:SI 16) ] ) -1 (nil) (barrier 82 81 28) Note carefully that we have a block that is just a label and an jump table. Danger, danger, danger. We eventually get into find_basic_blocks and this code: case JUMP_INSN: /* A basic block ends at a jump. */ if (head == NULL_RTX) head = insn; else { /* ??? Make a special check for table jumps. The way this happens is truely and amazingly gross. We are about to create a basic block that contains just a code label and an addr*vec jump insn. Worse, an addr_diff_vec creates its own natural loop. Prevent this bit of brain damage, pasting things together correctly in make_edges. The correct solution involves emitting the table directly on the tablejump instruction as a note, or JUMP_LABEL. */ if (GET_CODE (PATTERN (insn)) == ADDR_VEC || GET_CODE (PATTERN (insn)) == ADDR_DIFF_VEC) { head = end = NULL; n_basic_blocks--; break; } Which as far as I can tell has the effect of leaving the CODE_LABEL and ADDR_VEC in no-mans land (ie, not in any basic block). We then find that all the code after the ADDR_VEC is dead, so we delete it. So now we have something like [ ... block 0 ... ] [ ... block 1 ... ] (code_label 80) (jump_insn 81 (addr_vec ... )) (barier) (bunch-o-notes) (end of function) Where the code label and the jump insn are not in any basic block. This triggers an abort in global.c::make_insn_chain because it checks for the case where we find real insns after the last known basic block. One thought would be to try and have CSE kill the ADDR_VEC when it turns the tablejump into a simple jump. Another would be to have jump kill the unreachable ADDR_VEC. Another would be to not special case this stuff in find_basic_blocks_1 and instead either attach the insns to the previous block via merge_blocks or delete the block if we determine it is unreachable. Your thoughts would be appreciated. Here's the testcase for x86-linux -O2 extern int getch(); extern int class(); int token() { int state = 1; while (1) { int c=0; c = getch(); switch (state) { case 1: break; case 4: break; case 5: break; case 6: { switch (class(c)) { default: break; } } break; case 7: break; } } } From gcc-return-8680-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 04:30:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28091 invoked by alias); 2 Aug 1999 04:30:13 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28084 invoked from network); 2 Aug 1999 04:30:12 -0000 Received: from f255.hotmail.com (HELO hotmail.com) (207.82.251.146) by egcs.cygnus.com with SMTP; 2 Aug 1999 04:30:12 -0000 Received: (qmail 2875 invoked by uid 0); 2 Aug 1999 04:28:22 -0000 Message-ID: <19990802042822.2874.qmail@hotmail.com> Received: from 202.54.11.72 by www.hotmail.com with HTTP; Sun, 01 Aug 1999 21:28:21 PDT X-Originating-IP: [202.54.11.72] From: "Shiv Shankar Ramakrishnan" To: gcc@gcc.gnu.org Subject: RE: [ANN] gcc-2.95 binaries for x86-win32 targets Date: Mon, 02 Aug 1999 09:58:21 IST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Hi, I seem to be having problems with libstdc++ not being found by Mingw32 [gcc-2.95 ver from Mumit Khan's site]. It seems by default after unzipping, libstdc++.a is not present in the gccroot\lib dir. I had to copy it from gccroot\lib\gcc-lib\i386-mingw32\2.95 dir. BTW I am not using GCC_EXEC_PREFIX. What am I doing wrong? Also there are problems with the msvcrtruntime package ... but Mumit has already posted that a new fixed one will be available soon so thats okay. Juts as an aside is it possible to build Mingw32 such that it uses msvcrt.dll for itself also as opposed to crtdll.dll? Since after configuring Mingw32 for msvcrt, only the .exe's are made to use msvcrt and gcc itself uses crtdll. Any pointers to how to make gcc use msvcrt? Is it possible in the first place? Thanks, Shiv ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From gcc-return-8681-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 04:41:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29632 invoked by alias); 2 Aug 1999 04:41:02 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29625 invoked from network); 2 Aug 1999 04:41:01 -0000 Received: from mail0.u-aizu.ac.jp (163.143.1.43) by egcs.cygnus.com with SMTP; 2 Aug 1999 04:41:01 -0000 Received: from cai2ss10.u-aizu.ac.jp (cai2ss10 [163.143.28.59]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id NAA00895 for ; Mon, 2 Aug 1999 13:38:04 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by cai2ss10.u-aizu.ac.jp (8.9.3+3.1W/3.7Wistcmx+kanji) with ESMTP id NAA22730 for ; Mon, 2 Aug 1999 13:38:04 +0900 (JST) To: gcc@gcc.gnu.org Subject: Installation of GCC-2.95 for IRIX5.3 Reply-To: s1042080@u-aizu.ac.jp X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) X-URL: http://www.u-aizu.ac.jp/%7Es1042080/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990802133803M.s1042080@u-aizu.ac.jp> Date: Mon, 02 Aug 1999 13:38:03 +0900 From: Masahito Yoshida X-Dispatcher: imput version 990425(IM115) Lines: 59 My name is Masahito Yoshida, the university of aizu student. I successfully built and installed GCC for IRIX5.3. The following is installation log. % tar zxvf gcc-2.95.tar.gz % cd gcc-2.95 I edited source files. ./gcc/collect2.c 979: char *ld_suffix = "/usr/lib/old_ld"; 1655: fork_execute ("/usr/lib/old_ld", ld2_argv); ./gcc/config/mips/iris5.h 92:-32 -_SYSTYPE_SVR4 -rpath /usr/local/lib" % mkdir objdir % cd objdir % ../configure --host=mips-sgi-irix5.3 --target=mips-sgi-irix5.3 \ --build=mips-sgi-irix5.3 --prefix=/home/circle/nowp/usr/IRIX6/gnu \ --with-gnu-as --with-stabs --with-gcc % gmake bootstrap % gmake install % /home/circle/nowp/usr/IRIX6/gnu/bin/gcc -v Reading specs from /home/circle/nowp/usr/IRIX6/gnu/lib/gcc-lib/mips-sgi-irix5.3/2.95/specs gcc version 2.95 19990728 (release) config.stabs x---x---x---x---x---x---x---x---x---x---x---x---x---x---x---x---x---x---x #!/bin/sh # This file was generated automatically by configure. Do not edit. # This directory was configured as follows: /tmp/gcc-2.95/configure --with-gcc-version-trigger=/tmp/gcc-2.95/gcc/version.c --host=mips-sgi-irix5.3 --targ et=mips-sgi-irix5.3 --build=mips-sgi-irix5.3 --prefix=/home/circle/nowp/usr/IRIX6/gnu --with-gnu-as --with-st abs --with-gcc --norecursion # using "mh-frag" x---x---x---x---x---x---x---x---x---x---x---x---x---x---x---x---x---x---x I made a web page of installation log written by Japanese. The URL is http://www.u-aizu.ac.jp/circles/nowp/install/IRIX6/gcc-2.95.html Thank you. --- Masahito Yoshida s1042080@u-aizu.ac.jp From gcc-return-8682-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 04:49:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30758 invoked by alias); 2 Aug 1999 04:49:20 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30682 invoked from network); 2 Aug 1999 04:49:17 -0000 Received: from thor.xraylith.wisc.edu (198.150.6.11) by egcs.cygnus.com with SMTP; 2 Aug 1999 04:49:17 -0000 Received: from mercury.xraylith.wisc.edu (mercury.xraylith.wisc.edu [128.104.182.221]) by thor.xraylith.wisc.edu (8.9.1a/8.9.1) with ESMTP id XAA12114; Sun, 1 Aug 1999 23:47:37 -0500 Received: from mercury.xraylith.wisc.edu (localhost [127.0.0.1]) by mercury.xraylith.wisc.edu (8.8.7/8.8.7) with ESMTP id WAA27574; Sun, 1 Aug 1999 22:38:16 -0500 Message-Id: <199908020338.WAA27574@mercury.xraylith.wisc.edu> To: "Shiv Shankar Ramakrishnan" cc: gcc@gcc.gnu.org Subject: Re: [ANN] gcc-2.95 binaries for x86-win32 targets In-Reply-To: Your message of "Mon, 02 Aug 1999 09:58:21 +0700." <19990802042822.2874.qmail@hotmail.com> Date: Sun, 01 Aug 1999 22:38:15 -0500 From: Mumit Khan "Shiv Shankar Ramakrishnan" writes: > Hi, > I seem to be having problems with libstdc++ not being found by > Mingw32 [gcc-2.95 ver from Mumit Khan's site]. It seems by default > after unzipping, libstdc++.a is not present in the gccroot\lib dir. > I had to copy it from gccroot\lib\gcc-lib\i386-mingw32\2.95 dir. There's no need for (static) libstc++.a to be in the lib directory. It belongs in the same place where all the other language runtimes are such as libg2c etc. The compiler searches the compiler directory first, so there should be no problem. Lots of others are using it (I counted about 200 downloads by late evening), so unless you send me more info, I can't help. Please send me the following info (don't bother copying the list): $ g++ -v $ g++ -v -o foo foo.cc where foo.cc is a just a 'int main () { return 0; }' > BTW I am not using GCC_EXEC_PREFIX. What am I doing wrong? what about LIBRARY_PATH? > Also there are problems with the msvcrtruntime package ... but Mumit > has already posted that a new fixed one will be available soon so > thats okay. Yes. I won't have time until T or so to fix that. > > Juts as an aside is it possible to build Mingw32 such that it uses > msvcrt.dll for itself also as opposed to crtdll.dll? Since after > configuring Mingw32 for msvcrt, only the .exe's are made to use msvcrt > and gcc itself uses crtdll. Any pointers to how to make gcc use > msvcrt? Is it possible in the first place? Sure, but you need to use a cross-compiler since mingw can't be build natively using the normal configuration. Just configure it as i386-mingw32msvc instead of i386-mingw32. You'll probably need a Unix machine to build the cross and canadian cross compilers. For more info, check the crossgcc archives (http://www.objsw.com/). Regards, Mumit From gcc-return-8683-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 05:48:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4575 invoked by alias); 2 Aug 1999 05:48:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4568 invoked from network); 2 Aug 1999 05:48:28 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 2 Aug 1999 05:48:28 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id HAA22749; Mon, 2 Aug 1999 07:46:13 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id HAA00576; Mon, 2 Aug 1999 07:44:44 +0200 Date: Mon, 2 Aug 1999 07:44:44 +0200 Message-Id: <199908020544.HAA00576@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: kevinatk@home.com CC: egcs@egcs.cygnus.com In-reply-to: <37A517F4.482366F0@home.com> (message from Kevin Atkinson on Mon, 02 Aug 1999 00:00:52 -0400) Subject: Re: Improving C++ error messages References: <37A517F4.482366F0@home.com> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > I don't know what what would be the best solution to this problem is > but for god sakes something needs to be done as wading through what > all this means is a rather difficult task. Thanks for your bug report. Rest assured that the g++ maintainers are aware of the problem. > I would like to see a solution where the compile tracks keep tracks of > the typedef currently in uses that name instead of the fully expanded > one. I am not saying it would be easy but it would go a LONG way in > producing much for readable messages. g++ already uses the typedefs to shorten names of template instantiations. I don't know why it does not work in your case. Perhaps the typedef names where not used in the instantiations? > Also why does gcc only give the line number when giving an error > message. A character offset in many cases would be very useful as > often something like before '(' is not very useful when there is a > parse or syntax error as I have many '(' on one line. The problem is that the error messages are produced by cc1plus, after the preprocessor has already converted the input. Character positions are not meaningful, then, since macro expansions might have taken place. This could improve with cpplib integration. > I really hope someone will take me seriously. And, before you ask, I do > not have the knowledge or time to do it my self. Depends on what you mean by "seriously". If you expect to get a serious answer, well, I tried. If you mean that anybody is acting on any of those issues right now, or even in the near future - unlikely. Regards, Martin From gcc-return-8684-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 05:49:40 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5099 invoked by alias); 2 Aug 1999 05:49:39 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5084 invoked from network); 2 Aug 1999 05:49:38 -0000 Received: from anjala.mit.edu (root@18.251.3.144) by egcs.cygnus.com with SMTP; 2 Aug 1999 05:49:38 -0000 Received: (from arvind@localhost) by anjala.mit.edu (8.9.3/8.9.3) id BAA18486; Mon, 2 Aug 1999 01:48:09 -0400 X-Authentication-Warning: anjala.mit.edu: arvind set sender to arvinds@mit.edu using -f Date: Mon, 2 Aug 1999 01:48:09 -0400 From: Arvind Sankar To: Franz Sirl Cc: Arvind Sankar , gcc@gcc.gnu.org Subject: Re: On the RPM-spec (was: Re: gcc-2.95: Naming of the TAR file? GCC-2.95.tar.gz? gcc-2.95.tar.gz?) Message-ID: <19990802014809.A18467@anjala.mit.edu> Reply-To: Arvind Sankar References: <19990725110354.B14520@anjala.mit.edu> <99080111452700.00528@ns1102.munich.netsurf.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6us In-Reply-To: <99080111452700.00528@ns1102.munich.netsurf.de>; from Franz Sirl on Sun, Aug 01, 1999 at 11:17:57AM +0200 On Sun, Aug 01, 1999 at 11:17:57AM +0200, Franz Sirl wrote: > > --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD > Content-Type: text/plain > Content-Transfer-Encoding: 8bit > > Am Son, 25 Jul 1999 schrieb Arvind Sankar: > >>While on the subject of making an RPM, I used to make RPMS from the > >snapshots for RedHat Contrib|Net, and I've attached the .spec file and > >patches I needed. The .spec makes a couple of additional info files, runs > >the testsuite and packages the results, and adds libgcj to the RPM. > > Well, your spec is very similar to mine, the 2 basic differences are: > > 1. you configure for an optional compiler in /opt/egcs, I configure for a > system compiler in /usr ok, that should be changed. > 2. you follow the old RH5 layout (with libstdc++-devel), I follow the the RH6 > layout (with libstdc++-devel merged into gcc-c++ and a separate cpp) libstdc++.so is still a distinct package, tho, right? > > I don't care about about not-installed info files, because I believe they are > not installed on purpose :-). I only make sure that all info files are built > with --no-split to reduce the clutter in the info dir. Why _are_ those info files not generated? They look useful enough. Also, I don't see why clutter in the info dir matters. Using --no-split leads to HUGE info files. > > In the meantime, following some other discussions, I think the best approach > would really be to have 2 separate specs, one for use as a system compiler > (like mine) and one for use as an optional compiler (in /opt/gcc, /usr/local, > etc), cause the requirements during install are quite different. The > purpose/pitfalls of each spec should be clearly documented in it's header. ok. > > I already integrated some stuff out of your spec into my spec, and your spec > needs some overhaul egcs -> gcc :-). The only real nits I found in your spec, Ouch, where did I screw up? I thought I had caught everything? > you are building inside the sourcedir and you don't support any multilibbed How does building in a subdir of the sourcedir affect anything? And where would you build it otherwise? > target yet (look for %ifarch ppc/alpha in my spec). I think we should Yes, basically reason is that I don't have access to any machine for which multilibbed libraries are generated. -- arvind > synchronize a bit and then put up the specs for download (maybe in the > FTP infrastructure dir, with links from the FAQ/install pages). > > What do you think? > > Franz. > > --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD > Content-Type: text/english; > name="gcc-2.95-usr.spec" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="gcc-2.95-usr.spec" > > IwojIHRoaXMgc3BlYy1maWxlIHJlcXVpcmVzIHJwbS0zLjAgb3IgbmV3ZXIKIwolZGVmaW5lIEdD > Q19WRVJTSU9OIDIuOTUKJWRlZmluZSBTVERDX1ZFUlNJT04gMi4xMC4wCiVkZWZpbmUgdGFyZ2V0 > X2FsaWFzICV7X3RhcmdldF9jcHV9LWxpbnV4CiVkZWZpbmUgT0JKRElSICRSUE1fQlVJTERfRElS > L29iai1nY2MtJFJQTV9BUkNICgpTdW1tYXJ5OiBHTlUgQ29tcGlsZXIgQ29sbGVjdGlvbiAtIENv > cmUgcGFja2FnZSBpbmNsdWRpbmcgQyBjb21waWxlcgpOYW1lOiBnY2MKVmVyc2lvbjogJXtHQ0Nf > VkVSU0lPTn0KUmVsZWFzZTogMApDb3B5cmlnaHQ6IEdQTApHcm91cDogRGV2ZWxvcG1lbnQvTGFu > Z3VhZ2VzClNvdXJjZTogZnRwOi8vZ2NjLmdudS5vcmcvcHViL2djYy9yZWxlYXNlcy9nY2MtJXtH > Q0NfVkVSU0lPTn0vZ2NjLSV7R0NDX1ZFUlNJT059LnRhci5negpCdWlsZHJvb3Q6IC92YXIvdG1w > L2djYy0le0dDQ19WRVJTSU9OfS1yb290ClVybDogaHR0cDovL2djYy5nbnUub3JnLwpSZXF1aXJl > czogY3BwID0gJXtHQ0NfVkVSU0lPTn0KJWlmYXJjaCBwcGMKUmVxdWlyZXM6IGJpbnV0aWxzID49 > IDIuOS40LjAuOAolZWxzZQpSZXF1aXJlczogYmludXRpbHMgPj0gMi45LjEuMC4yMwolZW5kaWYK > T2Jzb2xldGVzOiBlZ2NzClByZXJlcTogL3NiaW4vaW5zdGFsbC1pbmZvCgolZGVzY3JpcHRpb24K > R0NDLCB0aGUgR05VIENvbXBpbGVyIENvbGxlY3Rpb24sIGlzIGEgZnJlZSBzb2Z0d2FyZSBwcm9q > ZWN0IHRoYXQgaW50ZW5kcyB0bwpmdXJ0aGVyIHRoZSBkZXZlbG9wbWVudCBvZiBHTlUgY29tcGls > ZXJzIHVzaW5nIGFuIG9wZW4gZGV2ZWxvcG1lbnQKZW52aXJvbm1lbnQuIFRoZSBnY2MgcGFja2Fn > ZSBjb250YWlucyB0aGUgR0NDIEMgY29tcGlsZXIsIGEgY29tcGlsZXIgYWltZWQKYXQgaW50ZWdy > YXRpbmcgYWxsIHRoZSBvcHRpbWl6YXRpb25zIGFuZCBmZWF0dXJlcyBuZWNlc3NhcnkgZm9yIGEK > aGlnaC1wZXJmb3JtYW5jZSBhbmQgc3RhYmxlIGRldmVsb3BtZW50IGVudmlyb25tZW50LgoKSW5z > dGFsbCBnY2MgaWYgeW91J2QgbGlrZSB0byB1c2UgdGhlIEdOVSBDb21waWxlciBDb2xsZWN0aW9u > IEMgY29tcGlsZXIsIHlvdQp3aWxsIGFsc28gbmVlZCB0byBpbnN0YWxsIHRoZSBjcHAgcGFja2Fn > ZS4KCiVwYWNrYWdlIC1uIGNwcApTdW1tYXJ5OiBHTlUgQ29tcGlsZXIgQ29sbGVjdGlvbiAtIFRo > ZSBDIFByZXByb2Nlc3Nvci4KR3JvdXA6IERldmVsb3BtZW50L0xhbmd1YWdlcwpQcmVyZXE6IC9z > YmluL2luc3RhbGwtaW5mbwoKJWRlc2NyaXB0aW9uIC1uIGNwcApUaGUgQyBwcmVwcm9jZXNzb3Ig > aXMgYSAnbWFjcm8gcHJvY2Vzc29yJyB3aGljaCBpcyB1c2VkIGF1dG9tYXRpY2FsbHkKYnkgdGhl > IEMgY29tcGlsZXIgdG8gdHJhbnNmb3JtIHlvdXIgcHJvZ3JhbSBiZWZvcmUgYWN0dWFsCmNvbXBp > bGF0aW9uLiBJdCBpcyBjYWxsZWQgYSBtYWNybyBwcm9jZXNzb3IgYmVjYXVzZSBpdCBhbGxvd3MK > eW91IHRvIGRlZmluZSAnbWFjcm9zJywgd2hpY2ggYXJlIGFiYnJldmlhdGlvbnMgZm9yIGxvbmdl > cgpjb25zdHJ1Y3RzLgoKVGhlIEMgcHJlcHJvY2Vzc29yIHByb3ZpZGVzIGZvdXIgc2VwYXJhdGUg > ZmFjaWxpdGllcyB0aGF0IHlvdSBjYW4gdXNlIGFzCnlvdSBzZWUgZml0OgoKKiBJbmNsdXNpb24g > b2YgaGVhZGVyIGZpbGVzLiBUaGVzZSBhcmUgZmlsZXMgb2YgZGVjbGFyYXRpb25zIHRoYXQgY2Fu > IGJlCiAgc3Vic3RpdHV0ZWQgaW50byB5b3VyIHByb2dyYW0uCiogTWFjcm8gZXhwYW5zaW9uLiBZ > b3UgY2FuIGRlZmluZSAnbWFjcm9zJywgd2hpY2ggYXJlIGFiYnJldmlhdGlvbnMgZm9yCiAgYXJi > aXRyYXJ5IGZyYWdtZW50cyBvZiBDIGNvZGUsIGFuZCB0aGVuIHRoZSBDIHByZXByb2Nlc3NvciB3 > aWxsIHJlcGxhY2UKICB0aGUgbWFjcm9zIHdpdGggdGhlaXIgZGVmaW5pdGlvbnMgdGhyb3VnaG91 > dCB0aGUgcHJvZ3JhbS4KKiBDb25kaXRpb25hbCBjb21waWxhdGlvbi4gVXNpbmcgc3BlY2lhbCBw > cmVwcm9jZXNzaW5nIGRpcmVjdGl2ZXMsCiAgeW91IGNhbiBpbmNsdWRlIG9yIGV4Y2x1ZGUgcGFy > dHMgb2YgdGhlIHByb2dyYW0gYWNjb3JkaW5nIHRvIHZhcmlvdXMKICBjb25kaXRpb25zLgoqIExp > bmUgY29udHJvbC4gSWYgeW91IHVzZSBhIHByb2dyYW0gdG8gY29tYmluZSBvciByZWFycmFuZ2Ug > c291cmNlIGZpbGVzCiAgaW50byBhbiBpbnRlcm1lZGlhdGUgZmlsZSB3aGljaCBpcyB0aGVuIGNv > bXBpbGVkLCB5b3UgY2FuIHVzZSBsaW5lCiAgY29udHJvbCB0byBpbmZvcm0gdGhlIGNvbXBpbGVy > IGFib3V0IHdoZXJlIGVhY2ggc291cmNlIGxpbmUgb3JpZ2luYXRlZC4KCllvdSBzaG91bGQgaW5z > dGFsbCB0aGlzIHBhY2thZ2UgaWYgeW91IGFyZSBhIHByb2dyYW1tZXIgd2hvIGlzIHNlYXJjaGlu > ZyBmb3IKc3VjaCBhIG1hY3JvIHByb2Nlc3Nvci4KCiVwYWNrYWdlIGMrKwpTdW1tYXJ5OiBDKysg > c3VwcG9ydCBmb3IgdGhlIEdOVSBDb21waWxlciBDb2xsZWN0aW9uLgpHcm91cDogRGV2ZWxvcG1l > bnQvTGFuZ3VhZ2VzClJlcXVpcmVzOiBjcHAgPSAle0dDQ19WRVJTSU9OfQpSZXF1aXJlczogZ2Nj > ID0gJXtHQ0NfVkVSU0lPTn0KUmVxdWlyZXM6IGxpYnN0ZGMrKyA9ICV7U1REQ19WRVJTSU9OfQpP > YnNvbGV0ZXM6IGVnY3MtYysrCk9ic29sZXRlczogbGlic3RkYysrLWRldmVsCk9ic29sZXRlczog > bGliZysrLWRldmVsCgolZGVzY3JpcHRpb24gYysrClRoaXMgcGFja2FnZSBhZGRzIEMrKyBzdXBw > b3J0IHRvIHRoZSBHTlUgY29tcGlsZXIgY29sbGVjdGlvbi4gSXQgaW5jbHVkZXMKc3VwcG9ydCBm > b3IgbW9zdCBvZiB0aGUgY3VycmVudCBDKysgc3BlY2lmaWNhdGlvbiwgaW5jbHVkaW5nIHRlbXBs > YXRlcyBhbmQKZXhjZXB0aW9uIGhhbmRsaW5nLiBJdCBkb2VzIGluY2x1ZGUgdGhlIHN0YXRpYyBz > dGFuZGFyZCBDKysgbGlicmFyeSBhbmQgQysrCmhlYWRlciBmaWxlczsgdGhlIGxpYnJhcnkgZm9y > IGR5bmFtaWNhbGx5IGxpbmtpbmcgcHJvZ3JhbXMgaXMgYXZhaWxhYmxlCnNlcGFyYXRlbHkuCgol > cGFja2FnZSBvYmpjClN1bW1hcnk6IE9iamVjdGl2ZSBDIHN1cHBvcnQgZm9yIHRoZSBHTlUgQ29t > cGlsZXIgQ29sbGVjdGlvbi4KR3JvdXA6IERldmVsb3BtZW50L0xhbmd1YWdlcwpSZXF1aXJlczog > Y3BwID0gJXtHQ0NfVkVSU0lPTn0KUmVxdWlyZXM6IGdjYyA9ICV7R0NDX1ZFUlNJT059ClJlcXVp > cmVzOiBnY2MtYysrID0gJXtHQ0NfVkVSU0lPTn0KT2Jzb2xldGVzOiBlZ2NzLW9iamMKCiVkZXNj > cmlwdGlvbiBvYmpjCk9iamVjdGl2ZSBDIGlzIGFuIG9iamVjdC1vcmllbnRlZCBkZXJpdmF0aXZl > IG9mIHRoZSBDIGxhbmd1YWdlLCBtdWNoIGxpa2UKQysrIGJ1dCB3aXRoIG1vcmUgZHluYW1pYyBj > YXBhYmlsaXRpZXMgdGhhbiB0aGlzLiBUaGlzIHBhY2thZ2UgYWRkcwpPYmplY3RpdmUtQyBzdXBw > b3J0IHRvIHRoZSBHTlUgQ29tcGlsZXIgQ29sbGVjdGlvbi4gSXQgaW5jbHVkZXMgdGhlCk9iamVj > dGl2ZS1DIGNvbXBpbGVyIGFuZCBydW50aW1lIHRoYXQgaXMgbmVlZGVkIGZvciBydW5uaW5nIE9i > amVjdGl2ZS1DCnByb2dyYW1zLgoKSW5zdGFsbCBnY2Mtb2JqYyBpZiB5b3UgYXJlIGdvaW5nIHRv > IGRvIE9iamVjdGl2ZSBDIGRldmVsb3BtZW50IGFuZCB5b3UKd291bGQgbGlrZSB0byB1c2UgdGhl > IEdOVSBDb21waWxlciBDb2xsZWN0aW9uLiAgWW91IHdpbGwgYWxzbyBuZWVkIHRvCmluc3RhbGwg > dGhlIGdjYyBwYWNrYWdlLgoKJXBhY2thZ2UgZzc3ClN1bW1hcnk6IEZvcnRyYW4gNzcgc3VwcG9y > dCBmb3IgdGhlIEdOVSBDb21waWxlciBDb2xsZWN0aW9uLgpHcm91cDogRGV2ZWxvcG1lbnQvTGFu > Z3VhZ2VzClJlcXVpcmVzOiBjcHAgPSAle0dDQ19WRVJTSU9OfQpSZXF1aXJlczogZ2NjID0gJXtH > Q0NfVkVSU0lPTn0KT2Jzb2xldGVzOiBlZ2NzLWc3NwpQcmVyZXE6IC9zYmluL2luc3RhbGwtaW5m > bwoKJWRlc2NyaXB0aW9uIGc3NwpUaGUgZ2NjLWc3NyBwYWNrYWdlIHByb3ZpZGVzIHN1cHBvcnQg > Zm9yIGNvbXBpbGluZyBGb3J0cmFuIDc3IHByb2dyYW1zIHdpdGgKdGhlIEdOVSBDb21waWxlciBD > b2xsZWN0aW9uLgoKWW91IHNob3VsZCBpbnN0YWxsIGdjYy1nNzcgaWYgeW91IGFyZSBnb2luZyB0 > byBkbyBGb3J0cmFuIGRldmVsb3BtZW50IGFuZAp5b3Ugd291bGQgbGlrZSB0byB1c2UgdGhlIEdO > VSBDb21waWxlciBDb2xsZWN0aW9uLiAgWW91IHdpbGwgYWxzbyBuZWVkIHRvCmluc3RhbGwgdGhl > IGdjYyBwYWNrYWdlLgoKJXBhY2thZ2UgamF2YQpTdW1tYXJ5OiBKYXZhIHN1cHBvcnQgZm9yIHRo > ZSBHTlUgQ29tcGlsZXIgQ29sbGVjdGlvbi4KR3JvdXA6IERldmVsb3BtZW50L0xhbmd1YWdlcwpS > ZXF1aXJlczogY3BwID0gJXtHQ0NfVkVSU0lPTn0KUmVxdWlyZXM6IGdjYyA9ICV7R0NDX1ZFUlNJ > T059ClJlcXVpcmVzOiBsaWJnY2oKUHJlcmVxOiAvc2Jpbi9pbnN0YWxsLWluZm8KCiVkZXNjcmlw > dGlvbiBqYXZhClRoZSBnY2MtamF2YSBwYWNrYWdlIHByb3ZpZGVzIHN1cHBvcnQgZm9yIGNvbXBp > bGluZyBKYXZhIHByb2dyYW1zCndpdGggdGhlIEdOVSBDb21waWxlciBDb2xsZWN0aW9uLgoKWW91 > IHNob3VsZCBpbnN0YWxsIGdjYy1qYXZhIGlmIHlvdSBhcmUgZ29pbmcgdG8gZG8gSmF2YSBkZXZl > bG9wbWVudCBhbmQgeW91CndvdWxkIGxpa2UgdG8gdXNlIHRoZSBHTlUgQ29tcGlsZXIgQ29sbGVj > dGlvbi4gIFlvdSB3aWxsIGFsc28gbmVlZCB0bwppbnN0YWxsIHRoZSBnY2MgcGFja2FnZSBhbmQg > dGhlIGxpYmdjaiBwYWNrYWdlLgoKJXBhY2thZ2UgY2hpbGwKU3VtbWFyeTogQ2hpbGwgc3VwcG9y > dCBmb3IgdGhlIEdOVSBDb21waWxlciBDb2xsZWN0aW9uLgpHcm91cDogRGV2ZWxvcG1lbnQvTGFu > Z3VhZ2VzClJlcXVpcmVzOiBjcHAgPSAle0dDQ19WRVJTSU9OfQpSZXF1aXJlczogZ2NjID0gJXtH > Q0NfVkVSU0lPTn0KUHJlcmVxOiAvc2Jpbi9pbnN0YWxsLWluZm8KCiVkZXNjcmlwdGlvbiBjaGls > bApUaGUgZ2NjLWNoaWxsIHBhY2thZ2UgcHJvdmlkZXMgc3VwcG9ydCBmb3IgY29tcGlsaW5nIENo > aWxsIHByb2dyYW1zIHdpdGggdGhlCkdOVSBDb21waWxlciBDb2xsZWN0aW9uLiBDaGlsbCBpcyB0 > aGUgIkNDSVRUIEhpZ2gtTGV2ZWwgTGFuZ3VhZ2UiLCB3aGVyZQpDQ0lUVCBpcyB0aGUgb2xkIG5h > bWUgZm9yIHdoYXQgaXMgbm93IElUVSwgdGhlIEludGVybmF0aW9uYWwKVGVsZWNvbW11bmljYXRp > b25zIFVuaW9uLiBJdCBpcyBpcyBsYW5ndWFnZSBpbiB0aGUgTW9kdWxhMiBmYW1pbHksIGFuZAp0 > YXJnZXRzIG1hbnkgb2YgdGhlIHNhbWUgYXBwbGljYXRpb25zIGFzIEFkYSAoZXNwZWNpYWxseSBs > YXJnZSBlbWJlZGRlZApzeXN0ZW1zKS4gQ2hpbGwgd2FzIG5ldmVyIHVzZWQgbXVjaCBpbiB0aGUg > VW5pdGVkIFN0YXRlcywgYnV0IGlzIHN0aWxsIGJlaW5nCnVzZWQgaW4gRXVyb3BlLCBCcmF6aWws > IEtvcmVhLCBhbmQgb3RoZXIgcGxhY2VzLgoKWW91IHdpbGwgYWxzbyBuZWVkIHRvIGluc3RhbGwg > dGhlIGdjYyBwYWNrYWdlLgoKJXBhY2thZ2UgLW4gbGlic3RkYysrClN1bW1hcnk6IGMrKyBsaWJy > YXJ5IGZvciB0aGUgR05VIENvbXBpbGVyIENvbGxlY3Rpb24uCkdyb3VwOiBTeXN0ZW0gRW52aXJv > bm1lbnQvTGlicmFyaWVzCk9ic29sZXRlczogbGliZysrClZlcnNpb246ICV7U1REQ19WRVJTSU9O > fQoKJWRlc2NyaXB0aW9uIC1uIGxpYnN0ZGMrKwpHTlUgQysrIHJ1bnRpbWUgbGlicmFyaWVzCgol > cHJlcAolc2V0dXAgLXEKIyB3ZSBkb24ndCBuZWVkIHRvIGJ1aWxkIHRleGluZm8gb24gYSBjdXJy > ZW50IExpbnV4IGluc3RhbGxhdGlvbgpybSAtcmYgdGV4aW5mbwoKJWJ1aWxkClNSQ0RJUj0iJFBX > RCIKcm0gLXJmICV7T0JKRElSfQpta2RpciAle09CSkRJUn0KY2QgJXtPQkpESVJ9CgokU1JDRElS > L2NvbmZpZ3VyZSBcCgktLXByZWZpeD0vdXNyIFwKCS0tZW5hYmxlLXNoYXJlZCBcCgktLWVuYWJs > ZS10aHJlYWRzIFwKCS0td2l0aC1jcHAtaW5zdGFsbC1kaXI9Li4vbGliIFwKCSV7dGFyZ2V0X2Fs > aWFzfSAyPiYxIHwgdGVlICRTUkNESVIvYnVpbGQubG9nCgpleHBvcnQgUEFUSD0kUEFUSDovc2Jp > bjovdXNyL3NiaW4KCm1ha2UgYm9vdHN0cmFwLWxlYW4gMj4mMSB8IHRlZSAtYSAkU1JDRElSL2J1 > aWxkLmxvZwoKIyB3b3JrYXJvdW5kIGEgYnVnIGluIHRoZSBoYW5kbGluZyBvZiBNQUtFSU5GTyBp > biBnY2MtMi45NQpmaW5kIC1uYW1lICIqLmluZm8ifHhhcmdzIHJtIC1mCmZpbmQgLW5hbWUgIiou > aW5mby1bMS05XSoifHhhcmdzIHJtIC1mCm1ha2UgaW5mbyBNQUtFSU5GTz0ibWFrZWluZm8gLS1u > by1zcGxpdCIgfCB0ZWUgLWEgJFNSQ0RJUi9idWlsZC5sb2cKCmlmIFsgLXggL3Vzci9iaW4vcnVu > dGVzdCBdOyB0aGVuCgltYWtlIC1rIGNoZWNrIDI+JjEgfCB0ZWUgLWEgJFNSQ0RJUi9idWlsZC5s > b2cKZWxzZQoJZWNobyAiRGVqYWdudSBub3QgaW5zdGFsbGVkLCBubyBzZWxmdGVzdHMgaGF2ZSBi > ZWVuIHJ1bi4iID4kU1JDRElSL2J1aWxkLmxvZwpmaQokU1JDRElSL2NvbnRyaWIvd2Fybl9zdW1t > YXJ5IDwkU1JDRElSL2J1aWxkLmxvZyA+JFNSQ0RJUi93YXJuLnN1bW1hcnkKJFNSQ0RJUi9jb250 > cmliL3Rlc3Rfc3VtbWFyeSAtaSAkU1JDRElSL3dhcm4uc3VtbWFyeSBcCgk+ICRTUkNESVIvY2hl > Y2suc3VtbWFyeQoKJWluc3RhbGwKU1JDRElSPSIkUFdEIgpybSAtcmYgJFJQTV9CVUlMRF9ST09U > CmNkICV7T0JKRElSfQoKZXhwb3J0IFBBVEg9JFBBVEg6L3NiaW46L3Vzci9zYmluCgptYWtlIGlu > c3RhbGwgXAoJcHJlZml4PSRSUE1fQlVJTERfUk9PVC91c3IgXAoJTUFLRUlORk89Im1ha2VpbmZv > IC0tbm8tc3BsaXQiCgpsbiAtc2YgZ2NjICRSUE1fQlVJTERfUk9PVC91c3IvYmluL2NjCmxuIC1z > ZiBnNzcgJFJQTV9CVUlMRF9ST09UL3Vzci9iaW4vZjc3CgpsbiAtc2YgZzc3LjEgJFJQTV9CVUlM > RF9ST09UL3Vzci9tYW4vbWFuMS9mNzcuMQpsbiAtc2YgY2NjcC4xICRSUE1fQlVJTERfUk9PVC91 > c3IvbWFuL21hbjEvY3BwLjEKCmd6aXAgLW4gLTlmICRSUE1fQlVJTERfUk9PVC91c3IvaW5mby8q > LmluZm8qIAoKJWNsZWFuCnJtIC1yZiAkUlBNX0JVSUxEX1JPT1QKCiVwb3N0Ci9zYmluL2luc3Rh > bGwtaW5mbyAtLWluZm8tZGlyPS91c3IvaW5mbyAvdXNyL2luZm8vZ2NjLmluZm8uZ3oKCiVwb3N0 > IC1uIGNwcAovc2Jpbi9pbnN0YWxsLWluZm8gLS1pbmZvLWRpcj0vdXNyL2luZm8gL3Vzci9pbmZv > L2NwcC5pbmZvLmd6CgolcG9zdCBnNzcKL3NiaW4vaW5zdGFsbC1pbmZvIC0taW5mby1kaXI9L3Vz > ci9pbmZvIC91c3IvaW5mby9nNzcuaW5mby5negoKJXByZXVuCmlmIFsgJDEgPSAwIF07IHRoZW4K > ICAgL3NiaW4vaW5zdGFsbC1pbmZvIC0tZGVsZXRlIC0taW5mby1kaXI9L3Vzci9pbmZvIC91c3Iv > aW5mby9nY2MuaW5mby5negpmaQoKJXByZXVuIC1uIGNwcAppZiBbICQxID0gMCBdOyB0aGVuCiAg > IC9zYmluL2luc3RhbGwtaW5mbyAtLWRlbGV0ZSAtLWluZm8tZGlyPS91c3IvaW5mbyAvdXNyL2lu > Zm8vY3BwLmluZm8uZ3oKZmkKCiVwcmV1biBnNzcKaWYgWyAkMSA9IDAgXTsgdGhlbgogICAvc2Jp > bi9pbnN0YWxsLWluZm8gLS1kZWxldGUgLS1pbmZvLWRpcj0vdXNyL2luZm8gL3Vzci9pbmZvL2c3 > Ny5pbmZvLmd6CmZpCgolcG9zdCAtbiBsaWJzdGRjKysgLXAgL3NiaW4vbGRjb25maWcKCiVwb3N0 > dW4gLW4gbGlic3RkYysrIC1wIC9zYmluL2xkY29uZmlnCgolZmlsZXMKJWRlZmF0dHIoLSxyb290 > LHJvb3QpCiVkb2MgUkVBRE1FKiBDT1BZSU5HIENPUFlJTkcuTElCIGNoZWNrLnN1bW1hcnkgd2Fy > bi5zdW1tYXJ5IGJ1aWxkLmxvZwolZGlyIC91c3IvbGliL2djYy1saWIKJWRpciAvdXNyL2xpYi9n > Y2MtbGliLyV7dGFyZ2V0X2FsaWFzfQolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxp > YXN9LyoKJWRpciAvdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2luY2x1ZGUKJWlm > YXJjaCBhbHBoYQolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovaWVlZQol > ZW5kaWYKJWlmYXJjaCBwcGMKJWRpciAvdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8q > L25vZgolZW5kaWYKCi91c3IvYmluLyV7dGFyZ2V0X2FsaWFzfS1nY2MKL3Vzci9iaW4vZ2Nvdgov > dXNyL2Jpbi9wcm90b2l6ZQovdXNyL2Jpbi91bnByb3RvaXplCi91c3IvYmluL2djYwovdXNyL2Jp > bi9jYwovdXNyL2luZm8vZ2NjKgovdXNyL21hbi9tYW4xL2djYy4xCi91c3IvJXt0YXJnZXRfYWxp > YXN9Ci91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovU1lTQ0FMTFMuYy5YCi91c3Iv > bGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovY2MxCi91c3IvbGliL2djYy1saWIvJXt0YXJn > ZXRfYWxpYXN9LyovY29sbGVjdDIKL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9s > aWJnY2MuYQolaWZhcmNoIGFscGhhIHBwYwovdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFz > fS8qLyovbGliZ2NjLmEKJWVuZGlmCiVpZm5hcmNoIGFscGhhCi91c3IvbGliL2djYy1saWIvJXt0 > YXJnZXRfYWxpYXN9LyovKmNydCoubwolZW5kaWYKL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9h > bGlhc30vKi9pbmNsdWRlL1JFQURNRQovdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8q > L2luY2x1ZGUvZmxvYXQuaAovdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2luY2x1 > ZGUvaXNvNjQ2LmgKL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9pbmNsdWRlL2xp > bWl0cy5oCi91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVkZS9wcm90by5o > Ci91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVkZS9zdGRhcmcuaAovdXNy > L2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2luY2x1ZGUvc3RkYm9vbC5oCi91c3IvbGli > L2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVkZS9zdGRkZWYuaAovdXNyL2xpYi9nY2Mt > bGliLyV7dGFyZ2V0X2FsaWFzfS8qL2luY2x1ZGUvc3lzbGltaXRzLmgKL3Vzci9saWIvZ2NjLWxp > Yi8le3RhcmdldF9hbGlhc30vKi9pbmNsdWRlL3ZhLSouaAovdXNyL2xpYi9nY2MtbGliLyV7dGFy > Z2V0X2FsaWFzfS8qL2luY2x1ZGUvdmFyYXJncy5oCiVpZmFyY2ggcHBjCi91c3IvbGliL2djYy1s > aWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVkZS8qLWFzbS5oCiVlbmRpZgoKCiVmaWxlcyAtbiBj > cHAKJWRlZmF0dHIoLSxyb290LHJvb3QpCiVkaXIgL3Vzci9saWIvZ2NjLWxpYgolZGlyIC91c3Iv > bGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9CiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3Rhcmdl > dF9hbGlhc30vKgolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVk > ZQolaWZhcmNoIGFscGhhCiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9p > ZWVlCiVlbmRpZgolaWZhcmNoIHBwYwolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxp > YXN9Lyovbm9mCiVlbmRpZgoKL2xpYi9jcHAKL3Vzci9iaW4vY3BwCi91c3IvaW5mby9jcHAqCi91 > c3IvbWFuL21hbjEvY3BwLjEKL3Vzci9tYW4vbWFuMS9jY2NwLjEKL3Vzci9saWIvZ2NjLWxpYi8l > e3RhcmdldF9hbGlhc30vKi9jcHAKL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9z > cGVjcwoKCiVmaWxlcyBjKysKJWRlZmF0dHIoLSxyb290LHJvb3QpCiVkaXIgL3Vzci9saWIvZ2Nj > LWxpYgolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9CiVkaXIgL3Vzci9saWIv > Z2NjLWxpYi8le3RhcmdldF9hbGlhc30vKgolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRf > YWxpYXN9LyovaW5jbHVkZQolaWZhcmNoIGFscGhhCiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3Rh > cmdldF9hbGlhc30vKi9pZWVlCiVlbmRpZgolaWZhcmNoIHBwYwolZGlyIC91c3IvbGliL2djYy1s > aWIvJXt0YXJnZXRfYWxpYXN9Lyovbm9mCiVlbmRpZgoKL3Vzci9iaW4vZysrCi91c3IvYmluL2Mr > KwovdXNyL2Jpbi9jKytmaWx0Ci91c3IvbWFuL21hbjEvZysrLjEKL3Vzci9pbmNsdWRlL2crKyoK > L3Vzci9saWIvbGlic3RkYysrKi5hCi91c3IvbGliL2xpYnN0ZGMrKyouYS4qCiVpZmFyY2ggYWxw > aGEgcHBjCi91c3IvbGliLyovbGlic3RkYysrKi5hCi91c3IvbGliLyovbGlic3RkYysrKi5hLioK > JWVuZGlmCi91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovY2MxcGx1cwovdXNyL2xp > Yi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2xpYnN0ZGMqCiVpZmFyY2ggYWxwaGEgcHBjCi91 > c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovKi9saWJzdGRjKgolZW5kaWYKL3Vzci9s > aWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9pbmNsdWRlL2V4Y2VwdGlvbgovdXNyL2xpYi9n > Y2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2luY2x1ZGUvbmV3Ci91c3IvbGliL2djYy1saWIvJXt0 > YXJnZXRfYWxpYXN9LyovaW5jbHVkZS90eXBlaW5mbwovdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0 > X2FsaWFzfS8qL2luY2x1ZGUvbmV3LmgKCgolZmlsZXMgb2JqYwolZGVmYXR0cigtLHJvb3Qscm9v > dCkKJWRpciAvdXNyL2xpYi9nY2MtbGliCiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9h > bGlhc30KJWRpciAvdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qCiVkaXIgL3Vzci9s > aWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9pbmNsdWRlCiVpZmFyY2ggYWxwaGEKJWRpciAv > dXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2llZWUKJWVuZGlmCiVpZmFyY2ggcHBj > CiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9ub2YKJWVuZGlmCgovdXNy > L2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2NjMW9iagovdXNyL2xpYi9nY2MtbGliLyV7 > dGFyZ2V0X2FsaWFzfS8qL2xpYm9iamMuYQovdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFz > fS8qL2luY2x1ZGUvb2JqYwoKCiVmaWxlcyBnNzcKJWRlZmF0dHIoLSxyb290LHJvb3QpCiVkaXIg > L3Vzci9saWIvZ2NjLWxpYgolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9CiVk > aXIgL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKgolZGlyIC91c3IvbGliL2djYy1s > aWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVkZQolaWZhcmNoIGFscGhhCiVkaXIgL3Vzci9saWIv > Z2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9pZWVlCiVlbmRpZgolaWZhcmNoIHBwYwolZGlyIC91 > c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9Lyovbm9mCiVlbmRpZgoKL3Vzci9iaW4vZzc3 > Ci91c3IvYmluL2Y3NwovdXNyL2luZm8vZzc3KgovdXNyL21hbi9tYW4xL2c3Ny4xCi91c3IvbWFu > L21hbjEvZjc3LjEKL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9mNzcxCi91c3Iv > bGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovbGliZzJjLmEKJWlmYXJjaCBhbHBoYSBwcGMK > L3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi8qL2xpYmcyYy5hCiVlbmRpZgovdXNy > L2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2luY2x1ZGUvZzJjLmgKCgolZmlsZXMgY2hp > bGwKJWRlZmF0dHIoLSxyb290LHJvb3QpCiVkaXIgL3Vzci9saWIvZ2NjLWxpYgolZGlyIC91c3Iv > bGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9CiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3Rhcmdl > dF9hbGlhc30vKgolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovaW5jbHVk > ZQolaWZhcmNoIGFscGhhCiVkaXIgL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9p > ZWVlCiVlbmRpZgolaWZhcmNoIHBwYwolZGlyIC91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxp > YXN9Lyovbm9mCiVlbmRpZgoKL3Vzci9iaW4vY2hpbGwKL3Vzci9saWIvZ2NjLWxpYi8le3Rhcmdl > dF9hbGlhc30vKi9jYzFjaGlsbAovdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfS8qL2No > aWxscnQwLm8KL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9saWJjaGlsbC5hCiVp > ZmFyY2ggYWxwaGEgcHBjCi91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovKi9jaGls > bHJ0MC5vCi91c3IvbGliL2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyovKi9saWJjaGlsbC5hCiVl > bmRpZgoKCiVmaWxlcyBqYXZhCiVkZWZhdHRyKC0scm9vdCxyb290KQolZGlyIC91c3IvbGliL2dj > Yy1saWIKJWRpciAvdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0X2FsaWFzfQolZGlyIC91c3IvbGli > L2djYy1saWIvJXt0YXJnZXRfYWxpYXN9LyoKJWRpciAvdXNyL2xpYi9nY2MtbGliLyV7dGFyZ2V0 > X2FsaWFzfS8qL2luY2x1ZGUKJWlmYXJjaCBhbHBoYQolZGlyIC91c3IvbGliL2djYy1saWIvJXt0 > YXJnZXRfYWxpYXN9LyovaWVlZQolZW5kaWYKJWlmYXJjaCBwcGMKJWRpciAvdXNyL2xpYi9nY2Mt > bGliLyV7dGFyZ2V0X2FsaWFzfS8qL25vZgolZW5kaWYKCi91c3IvYmluL2djagovdXNyL2Jpbi9n > Y2poCi91c3IvYmluL2pjZi1kdW1wCi91c3IvYmluL2p2LXNjYW4KL3Vzci9saWIvZ2NjLWxpYi8l > e3RhcmdldF9hbGlhc30vKi9qYzEKL3Vzci9saWIvZ2NjLWxpYi8le3RhcmdldF9hbGlhc30vKi9q > dmdlbm1haW4KCgolZmlsZXMgLW4gbGlic3RkYysrCiVkZWZhdHRyKC0scm9vdCxyb290KQolaWZh > cmNoIGFscGhhCiVkaXIgL3Vzci9saWIvaWVlZQolZW5kaWYKJWlmYXJjaCBwcGMKJWRpciAvdXNy > L2xpYi9ub2YKJWVuZGlmCgovdXNyL2xpYi9saWJzdGRjKysqLnNvCi91c3IvbGliL2xpYnN0ZGMr > Kyouc28uKgolaWZhcmNoIGFscGhhIHBwYwovdXNyL2xpYi8qL2xpYnN0ZGMrKyouc28KL3Vzci9s > aWIvKi9saWJzdGRjKysqLnNvLioKJWVuZGlmCgoKJWNoYW5nZWxvZwoqIEZyaSBKdWwgMTYgMTk5 > OSBGcmFueiBTaXJsIDxGcmFuei5TaXJsLWtlcm5lbEBsYXV0ZXJiYWNoLmNvbT4KICAtIG92ZXJo > YXVsZWQgdGhlIFJILTYuMCBzcGVjIChkb25lIGJ5IENyaXN0aWFuIEdhZnRvbiA8Z2FmdG9uQHJl > ZGhhdC5jb20+KQogICAgdG8gZml0IGdjYy0yLjk1Cg== > > --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD-- From gcc-return-8685-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 06:08:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9908 invoked by alias); 2 Aug 1999 06:08:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9901 invoked from network); 2 Aug 1999 06:08:27 -0000 Received: from eclipse.pacifier.com (199.2.117.78) by egcs.cygnus.com with SMTP; 2 Aug 1999 06:08:27 -0000 Received: from pacifier.com (bruceq@pacifier.com [199.2.117.161]) by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id XAA03127; Sun, 1 Aug 1999 23:06:57 -0700 (PDT) Date: Sun, 1 Aug 1999 23:07:01 -0700 (PDT) From: Bruce Q Hammond To: Daniel Berlin cc: egcs@egcs.cygnus.com Subject: RE: Contribution to egcs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 1 Aug 1999, Daniel Berlin wrote: > I'm not sure if the changes were merged with egcs yet, the Be changes seem > to have made it into the binutils (and other pieces, as soon as i get some > free time, i'll clean up my gdb changes and submit them), so the best place > may just be to grab the latest sources from geekgadgets. > It should also be on the R4.5 CD. > > Someone around here might know what version/date the latest GNUPro > distribution (99r2 i believe) is close to in the EGCS source tree (minus the > cygnus made changes, of course) I will check it out. Thanks. > > You are barking up the wrong tree, however. > IMHO. > I've barked up this one before. > What you really need to do is implement compression/removal of redundant > DWARF2 info into ld. > It's not an easy task. I know already that you are right about this. The redundant info is horid. > The easiest way to see if it's redundant info that's killing you is to make > one file that includes all the source files in your project, and > compile/link that. > If it's about 95% smaller, your problem is redundant DWARF2 info. > HTH, One thing that might help me to get started is finding docs on the DWARF2 spec / implemetation notes. I would like to find a way the the redundant info was not written to the .o files in the first place... perhaps an option for all the DWARF2 info to be written to a projectname.dwf file, limit the redundncy in some effecient way and modify the debugger to look for the dwarf info in that project.dwf file rather than in the executable. It might wind up being DWARF3 or some such thing. It sounds like a lot of work. Another thing that is of interest to me is implementation of precompiled headers for C/C++. Has anyone done a feasibility probe on this for egcs? I am certain that for some projects this would speed compiliation quite a bit. I may be getting ahead of myself before I have seen the source and implementation notes for the c++ compiler / DWARF2 etc. Pointers are appreciated. cheers, --BQ -------------------- Bruce Q. Hammond Gobe Software, Inc. From gcc-return-8686-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 06:18:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11112 invoked by alias); 2 Aug 1999 06:18:39 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11105 invoked from network); 2 Aug 1999 06:18:39 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 2 Aug 1999 06:18:39 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id AAA31937; Mon, 2 Aug 1999 00:15:50 -0600 X-Mailer: exmh version 2.0.2 To: Bruce Q Hammond cc: Daniel Berlin , egcs@egcs.cygnus.com Subject: Re: Contribution to egcs Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 01 Aug 1999 23:07:01 PDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Aug 1999 00:15:50 -0600 Message-ID: <31934.933574550@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > I would like to find a way the the redundant info was not written to the > .o files in the first place... perhaps an option for all the DWARF2 info > to be written to a projectname.dwf file, limit the redundncy in some > effecient way and modify the debugger to look for the dwarf info in that > project.dwf file rather than in the executable. It might wind up being > DWARF3 or some such thing. It sounds like a lot of work. It sounds like a lot of work down the wrong direction. I strongly recommend you pursue removing redundant stuff in the linker, possibly using additional information provided by the compiler (which is how stabs does it). > Another thing that is of interest to me is implementation of precompiled > headers for C/C++. Has anyone done a feasibility probe on this for egcs? > I am certain that for some projects this would speed compiliation quite a > bit. Not really. Or more correctly, there's some very tricky issues in the area of precompiled headers and by using a sane design for your code and header files you can avoid the problem in the first place. Furthermore, if you're optimizing, the vast majority of the compile time is in the optimizer. I also suggest you only try to tackle one problem at a time. jeff From gcc-return-8687-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 06:33:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12513 invoked by alias); 2 Aug 1999 06:33:38 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12506 invoked from network); 2 Aug 1999 06:33:37 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 2 Aug 1999 06:33:37 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990802063211.JJCJ9894.mail.rdc1.md.home.com@home.com>; Sun, 1 Aug 1999 23:32:11 -0700 Message-ID: <37A53BAE.2F4D28A4@home.com> Date: Mon, 02 Aug 1999 02:33:18 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Martin v. Loewis" CC: egcs@egcs.cygnus.com Subject: Re: Improving C++ error messages References: <37A517F4.482366F0@home.com> <199908020544.HAA00576@mira.isdn.cs.tu-berlin.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Martin v. Loewis" wrote: > > I would like to see a solution where the compile tracks keep tracks of > > the typedef currently in uses that name instead of the fully expanded > > one. I am not saying it would be easy but it would go a LONG way in > > producing much for readable messages. > > g++ already uses the typedefs to shorten names of template > instantiations. I don't know why it does not work in your > case. Perhaps the typedef names where not used in the instantiations? Could you pleace elaborate here.... > > Also why does gcc only give the line number when giving an error > > message. A character offset in many cases would be very useful as > > often something like before '(' is not very useful when there is a > > parse or syntax error as I have many '(' on one line. > > The problem is that the error messages are produced by cc1plus, after > the preprocessor has already converted the input. Character positions > are not meaningful, then, since macro expansions might have taken > place. This could improve with cpplib integration. Ok, I understand. How about providing a little more than just "before `one keyword'".... -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-8688-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 06:42:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13912 invoked by alias); 2 Aug 1999 06:42:08 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13905 invoked from network); 2 Aug 1999 06:42:06 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 2 Aug 1999 06:42:06 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.8.7/8.8.7) with ESMTP id XAA04248; Sun, 1 Aug 1999 23:42:42 -0700 To: law@cygnus.com Cc: bruceq@pacifier.com, dberlin@msn.com, egcs@egcs.cygnus.com Subject: Re: Contribution to egcs In-Reply-To: <31934.933574550@upchuck.cygnus.com> References: <31934.933574550@upchuck.cygnus.com> X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990801234242T.mitchell@codesourcery.com> Date: Sun, 01 Aug 1999 23:42:42 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 25 >>>>> "Jeffrey" == Jeffrey A Law writes: Jeffrey> It sounds like a lot of work down the wrong direction. I Jeffrey> strongly recommend you pursue removing redundant stuff in Jeffrey> the linker, possibly using additional information Jeffrey> provided by the compiler (which is how stabs does it). Since dwarf2 is a binary format, I wonder if using linkonce sections might not buy us a lot. Suppose there were a linkonce section for each type, say. Then, the other sections would contain relocations for the final location of this section. Presto, magic, the linker already knows how to deal with this. Similarly, we could have a dedicated dwarf2 section for each template instantiation, which would blow away duplicate debug info for template instantiations just like we already blow away code. (Do we already do this?) Of course, some profiling is in order to see what dwarf information is being replicated. (Is it types, as I assumed above? Or function declarations for functions in header files? ...) Just a thought off the top of my not-really-a-dwarf2-expert head. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-8689-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 08:15:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27828 invoked by alias); 2 Aug 1999 08:15:04 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27820 invoked by uid 22784); 2 Aug 1999 08:15:03 -0000 From: Anthony Green Newsgroups: cygnus.egcs Subject: Re: Contribution to egcs Date: 02 Aug 1999 01:01:02 -0700 Organization: Cygnus Solutions Lines: 15 Message-ID: References: NNTP-Posting-Host: fencer.cygnus.com X-Newsreader: Gnus v5.3/Emacs 19.34 To: egcs@egcs.cygnus.com DJ-Gateway: from newsgroup cygnus.egcs Bruce Q Hammond writes: > I would like to find a way the the redundant info was not written to the > o files in the first place... perhaps an option for all the DWARF2 info > to be written to a projectname.dwf file, Some of the gdb folks talk about simply leaving debug info in the object files and having gdb dig them up when required. If you are concerned about link times, this is probably your best bet. AG -- Anthony Green Cygnus Solutions Sunnyvale, California From gcc-return-8690-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 08:46:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30581 invoked by alias); 2 Aug 1999 08:46:12 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30566 invoked from network); 2 Aug 1999 08:46:11 -0000 Received: from dire.bris.ac.uk (137.222.10.60) by egcs.cygnus.com with SMTP; 2 Aug 1999 08:46:11 -0000 Received: from cs.bris.ac.uk (actually host luna.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Mon, 2 Aug 1999 09:44:42 +0100 Received: from acm.org (manao [137.222.102.67]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id JAA15787; Mon, 2 Aug 1999 09:42:18 +0100 (BST) Message-ID: <37A559E8.121458C4@acm.org> Date: Mon, 02 Aug 1999 09:42:16 +0100 From: Nathan Sidwell Reply-To: nathan@compsci.bristol.ac.uk Organization: University of Bristol X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Martin v. Loewis" CC: kevinatk@home.com, egcs@egcs.cygnus.com Subject: Re: Improving C++ error messages References: <37A517F4.482366F0@home.com> <199908020544.HAA00576@mira.isdn.cs.tu-berlin.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Martin v. Loewis" wrote: > g++ already uses the typedefs to shorten names of template > instantiations. I don't know why it does not work in your > case. Perhaps the typedef names where not used in the instantiations? The error message output for templates uses the cached template name (rather than synthesizing `X' at the message generation time). This of course means that the canonical template name is used which looks through typedefs. As it happens I've a rather substantial patch for the error dumping which gives better control over this kind of thing. The basic problem in error.c is that all the functions seriously overload the use of the `v' verbose flag to mean all sorts of different things in different contexts. I replaced this by a bit mask, separating each switch. I've not submitted this patch because I need to separate out some other bits from it and anyway didn't want to add to the backlog I've already got :-) I'll get round to it when my compute resource is fully functional again :-( nathan -- Dr Nathan Sidwell :: Computer Science Department :: Bristol University I have seen the death of PhotoShop -- it is called GIMP nathan@acm.org http://www.cs.bris.ac.uk/~nathan/ nathan@cs.bris.ac.uk From gcc-return-8691-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 09:18:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2131 invoked by alias); 2 Aug 1999 09:18:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2123 invoked from network); 2 Aug 1999 09:18:37 -0000 Received: from mail.rwth-aachen.de (137.226.144.9) by egcs.cygnus.com with SMTP; 2 Aug 1999 09:18:37 -0000 Received: from asterix.ika.rwth-aachen.de (ika-rohrpostix.ika.RWTH-Aachen.DE) by mail.rwth-aachen.de (PMDF V5.1-12 #D3869) with ESMTP id <01JEAG8MDALM000032@mail.rwth-aachen.de> for egcs@egcs.cygnus.com; Mon, 2 Aug 1999 11:16:46 +0200 Received: from MAJESTIX/SpoolDir by asterix.ika.rwth-aachen.de (Mercury 1.43) ; Mon, 02 Aug 1999 11:15:29 +0100 Received: from SpoolDir by MAJESTIX (Mercury 1.43); Mon, 02 Aug 1999 11:15:15 +0100 Date: Mon, 02 Aug 1999 11:15:06 +0100 From: Karsten Breuer Subject: Q: gcc/g77 To: egcs@egcs.cygnus.com Reply-to: Breuer@ika.rwth-aachen.de Message-id: <01JEAG8MDSI4000032@mail.rwth-aachen.de> Organization: ika MIME-version: 1.0 X-Mailer: Pegasus Mail for Win32 (v3.01d) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Priority: normal I have two questions about gcc/g77: 1) I'm using egcs based gcc and g77 (version egcs-2.91.66 19990314(egcs-1.1.2 release) (from FSF-g77 version 0.5.24- 19981002)) to compile C and Fortran77 on a Linux box with kernel 2.2.7. Is there a possibility to inline some C-Functions in the Fortran Code while linking the objects for a better performance of the executable? What statements or flags have to be used on the C and Fortran side? 2) Is there a possibility to use C allocated memory in Fortran? (e.g.: a C-subroutine do dptr = (double*)malloc(...*sizeof(double)) and I want to access this array out of Fortran without copying all it's values via the parameter list of the subroutine) Best regards K.Breuer From gcc-return-8692-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 09:42:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7694 invoked by alias); 2 Aug 1999 09:42:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7668 invoked from network); 2 Aug 1999 09:42:02 -0000 Received: from westgate.cyberway.com.sg (203.116.1.190) by egcs.cygnus.com with SMTP; 2 Aug 1999 09:42:02 -0000 Received: from rob.ildev (d146160.ppp146.cyberway.com.sg [203.116.146.160] (may be forged)) by westgate.cyberway.com.sg (8.9.3/8.8.5) with SMTP id RAA32615 for ; Mon, 2 Aug 1999 17:40:06 +0800 (SST) Message-Id: <199908020940.RAA32615@westgate.cyberway.com.sg> From: "Rob Kramer" To: egcs@egcs.cygnus.com Date: Mon, 2 Aug 1999 17:38:23 +0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Hmm. GCC 2.95 build fails on i586-pc-sco3.2v5.0.2 Reply-to: robk@cyberway.com.sg Priority: normal X-mailer: Pegasus Mail for Win32 (v3.01b) Hello, My build of gcc 2.95 fails on i586-pc-sco3.2v5.0.2. Before I go hunting, could someone tell me if this is a known problem? I configured as follows: [ildev2] /usr/rob/gnu/gcc-obj> ../gcc-2.95/configure --prefix=/usr/local/gcc-2.95 --with-gnu-as --enable-shared --disable-multilib --with-stabs --enable-languages=c++ And ran make: [ildev2] /usr/rob/gnu/gcc-obj> nice make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap But that goes wrong after a long while: make[4]: Entering directory `/usr/rob/gnu/gcc-obj/gcc' rm -f tmplibgcc2.a for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2 _lshrdi3 _ashldi3 _ashrdi3 _ffsdi2 _udiv_w_sdiv _udivmoddi4 _cmpdi2 _ucmpdi2 _floatdidf _floatdisf _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi _fixunssfdi _fixsfdi _fixxfdi _fixunsxfdi _floatdixf _fixunsxfsi _fixtfdi _fixunstfdi _floatditf __gcc_bcmp _varargs __dummy _eprintf _bb _shtab _clear_cache _trampoline __main _exit _ctors _pure; \ do \ echo ${name}; \ ./xgcc -B./ -B/usr/local/gcc-2.95/i586-pc-sco3.2v5.0.0/bin/ -I/usr/local/gcc- 2.95/i586-pc-sco3.2v5.0.0/include -O2 -DIN_GCC -g -I./include -g1 - DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I../../gcc-2.95/gcc - I../../gcc-2.95/gcc/config -I../../gcc-2.95/gcc/../include -c -DL${name} \ ../../gcc-2.95/gcc/libgcc2.c -o ${name}.o; \ if [ $? -eq 0 ] ; then true; else exit 1; fi; \ ar rc tmplibgcc2.a ${name}.o; \ rm -f ${name}.o; \ done _muldi3 Assembler: libgcc2.c aline 8 : Illegal mnemonic aline 8 : syntax error aline 12 : Illegal mnemonic aline 12 : syntax error aline 14 : Section definition must have attributes aline 16 : Illegal mnemonic aline 16 : syntax error aline 20 : Illegal mnemonic aline 20 : syntax error aline 22 : Section definition must have attributes aline 25 : Illegal mnemonic aline 25 : syntax error aline 26 : Illegal mnemonic aline 26 : syntax error aline 27 : Illegal mnemonic aline 27 : syntax error aline 28 : Illegal mnemonic aline 28 : syntax error aline 29 : Illegal mnemonic aline 29 : syntax error aline 31 : Illegal mnemonic aline 31 : syntax error aline 33 : Illegal mnemonic aline 33 : syntax error aline 34 : Illegal mnemonic aline 34 : syntax error aline 35 : Illegal mnemonic aline 35 : syntax error aline 36 : Illegal mnemonic aline 36 : syntax error aline 37 : Illegal mnemonic Too many errors - Goodbye make[4]: *** [libgcc2.a] Error 1 make[4]: Leaving directory `/usr/rob/gnu/gcc-obj/gcc' make[3]: *** [stmp-multilib-sub] Error 2 make[3]: Leaving directory `/usr/rob/gnu/gcc-obj/gcc' make[2]: *** [stmp-multilib] Error 1 make[2]: Leaving directory `/usr/rob/gnu/gcc-obj/gcc' make[1]: *** [bootstrap] Error 2 make[1]: Leaving directory `/usr/rob/gnu/gcc-obj/gcc' make: *** [bootstrap] Error 2 [ildev2] /usr/rob/gnu/gcc-obj> Cheers! Rob Kramer robk@cyberway.com.sg From gcc-return-8693-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 10:07:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10556 invoked by alias); 2 Aug 1999 10:07:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10539 invoked from network); 2 Aug 1999 10:07:26 -0000 Received: from bubble.ndsuk.com (194.216.129.248) by egcs.cygnus.com with SMTP; 2 Aug 1999 10:07:26 -0000 Received: from SMTP (emma.hedge.ndsuk.com [172.17.253.25]) by bubble.ndsuk.com (8.8.7/8.8.7) with SMTP id KAA31681; Mon, 2 Aug 1999 10:05:42 GMT Received: from sage.hedge.ndsuk.com ([172.17.253.10]) by 172.17.253.25 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 02 Aug 1999 10:00:04 0000 (GMT) Received: from ibm.net (ndsuk4908.stone.ndsuk.com [172.16.195.75]) by sage.hedge.ndsuk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id P6SS7YHJ; Mon, 2 Aug 1999 11:05:39 +0100 Message-ID: <37A56D73.5A7BA69A@ibm.net> Date: Mon, 02 Aug 1999 11:05:39 +0100 From: Etienne Lorrain Organization: Protection of the "jnp" instruction league X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: egcs@egcs.cygnus.com CC: bug-gnu-utils@gnu.org, ian@zembu.com, eliot@mgm.mit.edu, "H.J. Lu" Subject: gcc --target=i386-realmode Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, To follow on my E-mail few days ago, here is where the patch to GAS and the application I am playing with is stored: ftp://ftp.varesearch.com/pub/support/hjl/binutils/16bit Have a look first at: ftp://ftp.varesearch.com/pub/support/hjl/binutils/16bit/readme.1st You will find here few Kbytes of C source code compiling and running in real mode on a 80386+, to produce the first version of a bootloader. The patch to GAS is relative to binutils-2.9.5.0.3, and in fact is included in binutils-2.9.5.0.4, to be found at: (BETA versions) ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta/ I am still thinking that some parts of the GAS patch should go to the compiler, probably in GCC-3.0 because it is clearly to late for 2.95, but it is just IHMO. (more precisely, adding the "l" postfix to "call", "ret", "leave" because the compiler assumes 4 bytes address when referencing function parameters, i.e. "mov 4(%esp),%ax" for the last parameter of a function) Thanks for reading, Etienne. From gcc-return-8694-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 12:21:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31545 invoked by alias); 2 Aug 1999 12:21:39 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31537 invoked from network); 2 Aug 1999 12:21:34 -0000 Received: from unknown (HELO dancing-nancy.winnertech.com) (209.236.143.2) by egcs.cygnus.com with SMTP; 2 Aug 1999 12:21:34 -0000 Received: from danielbe3 ([208.252.226.226]) by dancing-nancy.winnertech.com (Netscape Mail Server v2.0) with SMTP id AAA187; Mon, 2 Aug 1999 09:20:37 -0400 From: "Daniel Berlin" To: "Bruce Q Hammond" Cc: Subject: RE: Contribution to egcs Date: Mon, 2 Aug 1999 08:19:48 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.3100 Importance: Normal > > One thing that might help me to get started is finding docs on the DWARF2 > spec / implemetation notes. Um, where did i see them last. Damnit. It's dwarf-2.0.0.*, just ftpsearch it. If you can't find it, i'll try to hunt it down. > > I would like to find a way the the redundant info was not written to the > .o files in the first place... perhaps an option for all the DWARF2 info > to be written to a projectname.dwf file, limit the redundncy in some > effecient way and modify the debugger to look for the dwarf info in that > project.dwf file rather than in the executable. It might wind up being > DWARF3 or some such thing. It sounds like a lot of work. Well, perhaps a little more detailed explanation of the problem would help. The problem actually occurs on all systems using DWARF2 info, AFAIK. It just is noticeable on BeOS because of the number of C++ headers the average file includes. What is happening is that the debug info for the "system" headers keeps getting output for every single file that you compile (or at least, a *lot* of the system headers). This generates a ton of debug info. 99% of it, is, of course, redundant. This is also the reason the "fatfile" trick (including source in one big file) works. It only sees the headers once, and only writes debug info once. Now, the immediate solution that comes to mind is to add a complete hack so that gcc knows that it already output debug info for the system headers, between compiles. Smart thinking, right? Wrong. You can't, because of the way DWARF2 works. See, the type info and whatnot in DWARF2 ends up being references to previous DWARF2 records (or future ones, or am i wrong about this. I'm trying to remember this, i apologize). Except for the first time it's output, of course. You'd have to add the ability for gcc to remember "DWARF2 state" between compiles, and then modify the linker to know this is what your doing (IE that it should merge the .o file with the system header debug info first) or else it wouldn't know where in the DWARF2 info "int" was (among other types and such), and things would really get screwed up. DWARF2 is pretty convoluted in this respect. It seems nobody ever stopped to think about the problem when writing the spec. Like if someone actually started *using* it for large C++ projects, well, we'd just figure out what to do then. Welcome to then. Another solution i can think of off the top of my head is to somehow output something (DWARF2 has room for extensions) that tells it "oh, this type is in a system header, we'll let LD figure out the real reference number", and then modify ld to do just that. I had some better ideas when i spent about 2 weeks doing nothing but trying to figure out how to solve this problem, but i determined rather quickly that any solution would take me months to implement, and i don't have the free time. :( > > I may be getting ahead of myself before I have seen the source and > implementation notes for the c++ compiler / DWARF2 etc. > > Pointers are appreciated. Dwarf2out.c is your friend and enemy. > > > cheers, > --BQ > -------------------- > Bruce Q. Hammond > Gobe Software, Inc. > > > > > > > > From gcc-return-8695-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 12:40:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 611 invoked by alias); 2 Aug 1999 12:39:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 597 invoked from network); 2 Aug 1999 12:39:27 -0000 Received: from mailhub2.shef.ac.uk (143.167.2.154) by egcs.cygnus.com with SMTP; 2 Aug 1999 12:39:27 -0000 Received: from gold.shef.ac.uk ([143.167.2.5]) by mailhub2 with esmtp (Exim 3.02 #2) id 11BHKU-0002h2-00 for gcc@gcc.gnu.org; Mon, 02 Aug 1999 13:36:34 +0100 Received: from ap1jjg (helo=localhost) by gold.shef.ac.uk with local-smtp (Exim 2.01 #1) for gcc@gcc.gnu.org id 11BHKU-0000iD-00; Mon, 2 Aug 1999 13:36:34 +0100 Date: Mon, 2 Aug 1999 13:36:34 +0100 (BST) From: "J.J.Green" X-Sender: ap1jjg@gold To: gcc@gcc.gnu.org Subject: solaris 2.7 install Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello gcc people The new gcc 2.95 compiles without problems straight out of the box acms22:> ./config.guess sparc-sun-solaris2.7 Many thanks for the best of compilers! Jim Green -- J.J. Green, The Dept. Applied Mathematics, F40, The Hicks Building, Houndsfield Rd., The University of Sheffield, Sheffield, UK. (0114) 222 3742, j.j.green@sheffield.ac.uk http://www.arbs.demon.co.uk From gcc-return-8696-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 12:49:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9117 invoked by alias); 2 Aug 1999 12:49:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8815 invoked from network); 2 Aug 1999 12:49:40 -0000 Received: from piglet.chem-eng.nwu.edu (129.105.205.250) by egcs.cygnus.com with SMTP; 2 Aug 1999 12:49:40 -0000 Received: (qmail 29368 invoked by uid 1122); 2 Aug 1999 12:47:43 -0000 Message-ID: <19990802124742.25777.qmail@piglet.chem-eng.nwu.edu> Date: 2 Aug 1999 07:47:42 -0500 From: "David J. Dooling" To: gcc@gcc.gnu.org Subject: successful build Reply-to: d-dooling@nwu.edu mips-sgi-irix6.2 thanks. From gcc-return-8697-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 12:59:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13614 invoked by alias); 2 Aug 1999 12:59:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13594 invoked from network); 2 Aug 1999 12:58:58 -0000 Received: from host162.nashville.com (HELO rjlhome.sco.com) (207.65.231.162) by egcs.cygnus.com with SMTP; 2 Aug 1999 12:58:58 -0000 Received: (from robertl@localhost) by rjlhome.sco.com (8.8.8/SCO5) id HAA20521; Mon, 2 Aug 1999 07:56:54 -0500 (CDT) Date: Mon, 2 Aug 1999 07:56:53 -0500 From: Robert Lipe To: Rob Kramer Cc: egcs@egcs.cygnus.com Subject: Re: Hmm. GCC 2.95 build fails on i586-pc-sco3.2v5.0.2 Message-ID: <19990802075653.I6067@rjlhome.sco.com> References: <199908020940.RAA32615@westgate.cyberway.com.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95us In-Reply-To: <199908020940.RAA32615@westgate.cyberway.com.sg>; from Rob Kramer on Mon, Aug 02, 1999 at 05:38:23PM +0800 > My build of gcc 2.95 fails on i586-pc-sco3.2v5.0.2. Before I go hunting, > could someone tell me if this is a known problem? I configured as follows: It's sort of a known problem. I'm not 100% certain of this, but I believe you were simply inconsistent about lying to the compiler. :-) > [ildev2] /usr/rob/gnu/gcc-obj> ../gcc-2.95/configure > --prefix=/usr/local/gcc-2.95 --with-gnu-as --enable-shared > --disable-multilib --with-stabs --enable-languages=c++ Here, you absolutely promised the tools that you have a GNU assembler compiled to emit ELF and installed as 'as' that will be found in your $PATH before the system assembler. > ./xgcc -B./ -B/usr/local/gcc-2.95/i586-pc-sco3.2v5.0.0/bin/ -I/usr/local/gcc- > 2.95/i586-pc-sco3.2v5.0.0/include -O2 -DIN_GCC -g -I./include -g1 - > DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I../../gcc-2.95/gcc - > I../../gcc-2.95/gcc/config -I../../gcc-2.95/gcc/../include -c -DL${name} \ > ../../gcc-2.95/gcc/libgcc2.c -o ${name}.o; \ > Assembler: libgcc2.c > aline 8 : Illegal mnemonic > aline 8 : syntax error > aline 12 : Illegal mnemonic > aline 12 : syntax error > aline 14 : Section definition must have attributes The experienced eye recognizes this as the type of failure you get when you feed the compiler's ELF output into a COFF assembler. Either quit telling it you have GNU as or stack the deck so that the tools can find a functional GNU as. RJL From gcc-return-8698-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 14:42:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20967 invoked by alias); 2 Aug 1999 14:42:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20960 invoked from network); 2 Aug 1999 14:42:39 -0000 Received: from binky.de.uu.net (192.76.144.28) by egcs.cygnus.com with SMTP; 2 Aug 1999 14:42:39 -0000 Received: from cerebro (pec-42.au1.ka.uunet.de [149.228.138.42]) by binky.de.uu.net (5.5.5/5.5.5) with ESMTP id QAA16920 for ; Mon, 2 Aug 1999 16:40:18 +0200 (MET DST) Received: from root by cerebro with local (Exim 2.10 #2) id 11B7iY-0001oz-00 for egcs@egcs.cygnus.com; Mon, 2 Aug 1999 04:20:46 +0200 Date: Mon, 2 Aug 1999 04:20:46 +0200 To: egcs mailing list Subject: Re: Wherefore art thou 2.95 Announcement? Message-ID: <19990802042046.F5005@cerebro.laendle> References: <29728.933520798@upchuck.cygnus.com> <37A4B06F.9652339D@switchco.com> <3.0.6.32.19990801142449.00835470@mail.ofe.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <3.0.6.32.19990801142449.00835470@mail.ofe.org>; from David Starner on Sun, Aug 01, 1999 at 02:24:49PM -0700 X-Operating-System: Linux version 2.2.10 (root@cerebro) (gcc driver version egcs-2.91.66 19990314 (egcs-1.1.2 release) executing gcc version 2.7.2.3) From: Marc Lehmann On Sun, Aug 01, 1999 at 02:24:49PM -0700, David Starner wrote: > >The egcs project was successful, in large part, due to the > >autonomy of the development group and the good sense of its main > >personnel (like Jeff for instance). > > The same development group is still there. The GCC steering commitee is the > EGCS steering committee. And most important: the steering committee is _exactly_ the same. Just as it was independent of any special group or company, it is now independent of any single group or company, including the fsf. > It didn't come to a standstill, it merely slowed way down. The fact that I think it came to a complete standstill. The last mail I received for the gcc2 developers list was in April. > >The whole "Cathedral vs. Bazaar" thing > >comes into play here in a big way. > There is no plans to make the way GCC is developed any different from the > way egcs was. Exactly! > >Otherwise, some one please tell me > >what the heck was the benefit of becoming the "official gcc" > >again?!?!? egcs was superiour to gcc, no doubt, but it still had this (wrong) "experimental" sticker on it, and people (linux distributors, software vendors etc..) were reluctant to use it. The thing _is_ named GCC, no matter how you put it. The name is of great historical relevance, and this was one of the reasons the name name has the same abbreviation as the old: "GCC". Having two projects (no matter how dead gcc really was) did no good to either version. The original goal - open development (in the broadest sense) was achieved, and so it is a good thing that egcs returned to its original name. -- -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | From gcc-return-8699-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 15:06:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22858 invoked by alias); 2 Aug 1999 15:06:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22851 invoked from network); 2 Aug 1999 15:06:43 -0000 Received: from unknown (HELO smtprch1.nortel.com) (192.135.215.14) by egcs.cygnus.com with SMTP; 2 Aug 1999 15:06:43 -0000 Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Mon, 2 Aug 1999 09:57:58 -0500 Received: from zmtlde5a.ca.nortel.com ([47.64.13.90]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id P2BGR43G; Mon, 2 Aug 1999 11:05:19 -0400 Received: from wmtl249c.nortel.ca (wmtl249c.ca.nortel.com [47.64.3.156]) by zmtlde5a.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PRPKXNVN; Mon, 2 Aug 1999 11:05:18 -0400 From: "Jerry Quinn" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14245.45996.480771.600072@gargle.gargle.HOWL> Date: Mon, 2 Aug 1999 11:05:16 -0400 (EDT) To: gcc@gcc.gnu.org Subject: Simple RTL question (was: New cfg code) In-Reply-To: <31298.933567296@upchuck.cygnus.com> References: <31298.933567296@upchuck.cygnus.com> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) X-Orig: (subject changed because it's unrelated to the thread) For fun I was trying to understand this example and had a quick question that I couldn't answer in the docs: >> "jeff" == Jeffrey A Law writes: jeff> (code_label 80 79 81 15 "" [num uses: 2]) In the info docs, it says that (code_label) has two extra fields - CODE_LABEL_NUMBER and LABEL_NUSES. The label number appears to be 15 and the number of uses is 2. What is the empty string? Is it actually part of the rtl expression or an artifact of printing? I'm guessing it contains the string assigned to the code label, but wanted verification. Is this worth mentioning in the RTL docs? Thanks Jerry -- Jerry Quinn Tel: (514) 761-8737 jquinn@nortelnetworks.com Fax: (514) 761-8505 Speech Recognition Research From gcc-return-8700-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 15:15:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24247 invoked by alias); 2 Aug 1999 15:15:20 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24232 invoked from network); 2 Aug 1999 15:15:12 -0000 Received: from sunsite.ms.mff.cuni.cz (195.113.19.66) by egcs.cygnus.com with SMTP; 2 Aug 1999 15:15:12 -0000 Received: (from jj@localhost) by sunsite.ms.mff.cuni.cz (8.9.3/8.9.3) id RAA10023; Mon, 2 Aug 1999 17:15:08 +0200 Date: Mon, 2 Aug 1999 17:15:08 +0200 From: Jakub Jelinek To: Jerry Quinn Cc: gcc@gcc.gnu.org Subject: Re: Simple RTL question (was: New cfg code) Message-ID: <19990802171508.I548@mff.cuni.cz> References: <31298.933567296@upchuck.cygnus.com> <14245.45996.480771.600072@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <14245.45996.480771.600072@gargle.gargle.HOWL>; from Jerry Quinn on Mon, Aug 02, 1999 at 11:05:16AM -0400 On Mon, Aug 02, 1999 at 11:05:16AM -0400, Jerry Quinn wrote: > (subject changed because it's unrelated to the thread) > > For fun I was trying to understand this example and had a quick question that > I couldn't answer in the docs: > > >> "jeff" == Jeffrey A Law writes: > > jeff> (code_label 80 79 81 15 "" [num uses: 2]) > > In the info docs, it says that (code_label) has two extra fields - > CODE_LABEL_NUMBER and LABEL_NUSES. The label number appears to be 15 and the > number of uses is 2. What is the empty string? Is it actually part of the > rtl expression or an artifact of printing? I'm guessing it contains the > string assigned to the code label, but wanted verification. Read rtl.def and rtl.h. 15 is CODE_LABEL_NUMBER, "" is the user assigned string (none in this case) and in the two hidden fields are LABEL_NUSES and LABEL_REFS. Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz Administrator of SunSITE Czech Republic, MFF, Charles University ___________________________________________________________________ UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/ Linux version 2.3.13 on a sparc64 machine (1343.49 BogoMips) ___________________________________________________________________ From gcc-return-8701-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 15:17:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24584 invoked by alias); 2 Aug 1999 15:17:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24574 invoked from network); 2 Aug 1999 15:17:14 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 2 Aug 1999 15:17:14 -0000 Received: (qmail 6250 invoked by alias); 2 Aug 1999 15:15:51 -0000 Received: (qmail 6242 invoked from network); 2 Aug 1999 15:15:51 -0000 Received: from biriani.cygnus.co.uk (bernds@194.130.39.16) by dns.cygnus.co.uk with SMTP; 2 Aug 1999 15:15:51 -0000 Received: from localhost by biriani.cygnus.co.uk (UUNET PIPEX simple 1.30) id QAA25871; Mon, 2 Aug 1999 16:15:46 +0100 Date: Mon, 2 Aug 1999 16:15:44 +0100 (BST) From: Bernd Schmidt To: Jerry Quinn cc: gcc@gcc.gnu.org Subject: Re: Simple RTL question (was: New cfg code) In-Reply-To: <14245.45996.480771.600072@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > For fun I was trying to understand this example and had a quick question that > I couldn't answer in the docs: > > jeff> (code_label 80 79 81 15 "" [num uses: 2]) > > In the info docs, it says that (code_label) has two extra fields - > CODE_LABEL_NUMBER and LABEL_NUSES. The label number appears to be 15 and the > number of uses is 2. What is the empty string? Is it actually part of the > rtl expression or an artifact of printing? I'm guessing it contains the > string assigned to the code label, but wanted verification. All the rtl expressions are defined (and documented) in the rtl.def file. The section for CODE_LABEL is this: /* Holds a label that is followed by instructions. Operand: 3: is a number that is unique in the entire compilation. 4: is the user-given name of the label, if any. 5: is used in jump.c for the use-count of the label. 6: is used in flow.c to point to the chain of label_ref's to this label. */ The string will be non-empty for user-declared labels, empty for internally generated ones. You can access it with the LABEL_NAME macro. Bernd From gcc-return-8702-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 15:56:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30133 invoked by alias); 2 Aug 1999 15:56:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30122 invoked from network); 2 Aug 1999 15:56:54 -0000 Received: from smtprtp1.nortel.net (137.118.22.14) by egcs.cygnus.com with SMTP; 2 Aug 1999 15:56:54 -0000 Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprtp1.nortel.net; Mon, 2 Aug 1999 11:55:15 -0400 Received: from zmtlde5a.ca.nortel.com ([47.64.13.90]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id P2BFXY1Y; Mon, 2 Aug 1999 11:55:13 -0400 Received: from wmtl249c.nortel.ca (wmtl249c.ca.nortel.com [47.64.3.156]) by zmtlde5a.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PRPKXNX6; Mon, 2 Aug 1999 11:55:14 -0400 From: "Jerry Quinn" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14245.48992.142999.156653@gargle.gargle.HOWL> Date: Mon, 2 Aug 1999 11:55:12 -0400 (EDT) To: Bernd Schmidt Cc: "Jerry Quinn" , gcc@gcc.gnu.org Subject: Re: Simple RTL question (was: New cfg code) In-Reply-To: References: <14245.45996.480771.600072@gargle.gargle.HOWL> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) >> "Bernd" == Bernd Schmidt writes: >> For fun I was trying to understand this example and had a quick question >> that I couldn't answer in the docs: >> jeff> (code_label 80 79 81 15 "" [num uses: 2]) >> In the info docs, it says that (code_label) has two extra fields - >> CODE_LABEL_NUMBER and LABEL_NUSES. The label number appears to be 15 and >> the number of uses is 2. What is the empty string? Is it actually part >> of the rtl expression or an artifact of printing? I'm guessing it >> contains the string assigned to the code label, but wanted verification. Bernd> All the rtl expressions are defined (and documented) in the rtl.def Bernd> file. The section for CODE_LABEL is this: /* Holds a label that is Bernd> followed by instructions. Operand: 3: is a number that is unique in Bernd> the entire compilation. 4: is the user-given name of the label, if Bernd> any. 5: is used in jump.c for the use-count of the label. 6: is used Bernd> in flow.c to point to the chain of label_ref's to this label. */ OK, so the info docs are out of synch. If nobody else does, I'll submit an update. Thanks for the replies Jerry -- Jerry Quinn Tel: (514) 761-8737 jquinn@nortelnetworks.com Fax: (514) 761-8505 Speech Recognition Research From gcc-return-8703-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 16:04:17 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32245 invoked by alias); 2 Aug 1999 16:04:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32235 invoked from network); 2 Aug 1999 16:04:15 -0000 Received: from dhcp41.moberg.com (207.8.227.41) by egcs.cygnus.com with SMTP; 2 Aug 1999 16:04:15 -0000 Received: (from george@localhost) by dhcp41.moberg.com (8.8.7/8.8.7) id MAA07311 for gcc@gcc.gnu.org; Mon, 2 Aug 1999 12:06:42 -0400 Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 02 Aug 1999 12:06:42 -0400 (EDT) Reply-To: george@moberg.com Organization: Moberg Research, Inc. From: george@moberg.com To: gcc@gcc.gnu.org Subject: Unrecognized insn internal error in egcs 1.1.2 OK, I'm pulling my hair out. 1.1.2 is giving me this weird error on Linux IA32 while compiling a C++ program. Should I update to 2.95? If you reply, please CC me as I get the digest. Thanks. Here's my command line: eg_g++ -g -c -Wall -ansi -pedantic -O2 -DNDEBUG -I. -I/usr/local/libmrc/include -I../../common -Itransforms -D_GNU_SOURCE -D_REENTRANT -DPLATFORM_LINUX=1 -DEXPORT= -fno-implicit-templates -fnew-exceptions -fasynchronous-exceptions -fvtable-thunks -fexceptions Here's the weird error: TransformConnectionComponent.cpp -o TransformConnectionComponent.ot TransformConnectionComponent.cpp: In method 'void CTransformConnectionComponent::_OpenDataConnection(const char *, const char *)': TransformConnectionComponent.cpp:178: internal error--unrecognizable insn: (insn 284 624 286 (set (reg:SI 48) (mem/s:SI (plus:SI (mem:SI (reg:SI 88)) (const_int 12)))) -1 (insn_list 624 (nil)) (nil)) ../../egcs-1.1.2/gcc/toplev.c:1367: Internal compiler error in function fatal_insn make: *** [TransformConnectionComponent.ot] Error 1 Here's the relevant code: void CTransformConnectionComponent::_OpenDataConnection(\ const char *szDataType, const char * szTarget) { Address target(szTarget); CAspects type(szDataType); COutputSink *pOutput = new COutputSink(target, type, *this); try { m_pOutputTransformations->NewOutput(type, pOutput); } catch (...) { delete pOutput; throw; } m_Outputs.Add(pOutput); } Line 178 is the closing brace of the function. Is there something I can do to provide more information about this error? --- George T. Talbot From gcc-return-8704-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 16:07:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 208 invoked by alias); 2 Aug 1999 16:07:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 201 invoked from network); 2 Aug 1999 16:07:13 -0000 Received: from templar.arc.nasa.gov (128.102.186.37) by egcs.cygnus.com with SMTP; 2 Aug 1999 16:07:13 -0000 Received: by templar.arc.nasa.gov (980427.SGI.8.8.8/1.35) id JAA05728; Mon, 2 Aug 1999 09:11:53 -0700 (PDT) Date: Mon, 2 Aug 1999 09:11:53 -0700 (PDT) From: karl@templar.arc.nasa.gov (Karl Schweighofer) Message-Id: <199908021611.JAA05728@templar.arc.nasa.gov> To: egcs@egcs.cygnus.com Subject: Errors installing with "make install" Hi, I am having problems at the install stage. The output of config.guess for my system is: mips-sgi-irix5.3 When installing by using "make install" it tries to recompile things, and I get this error: collect2: ld returned 1 exit status /usr/bin/../lib/ld: Object file format error in: reload1.o: bad sc in external symbol: *** Error code 1 (bu21) Can anyone help me? Sincerely, -Karl Dr. Karl J. Schweighofer NASA Ames Research Center Mail Stop 239-4 Moffett Field CA 94035 (650) 604-5496 From gcc-return-8705-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 16:20:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3838 invoked by alias); 2 Aug 1999 16:20:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3829 invoked from network); 2 Aug 1999 16:20:54 -0000 Received: from mescaline.gnu.org (158.121.106.21) by egcs.cygnus.com with SMTP; 2 Aug 1999 16:20:54 -0000 Received: from hamachi.synopsys.com (hamachi.synopsys.com [204.176.20.26]) by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id MAA19207 for ; Mon, 2 Aug 1999 12:19:30 -0400 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id JAA18549; Mon, 2 Aug 1999 09:17:20 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id JAA29448; Mon, 2 Aug 1999 09:17:20 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id JAA01845; Mon, 2 Aug 1999 09:17:19 -0700 Message-Id: <199908021617.JAA01845@atrus.synopsys.com> Subject: Re: Unrecognized insn internal error in egcs 1.1.2 To: george@moberg.com Date: Mon, 2 Aug 99 9:17:19 PDT Cc: gcc@gcc.gnu.org In-Reply-To: ; from "george@moberg.com" at Aug 2, 99 12:06 pm X-Mailer: ELM [version 2.3 PL11] > OK, I'm pulling my hair out. 1.1.2 is giving me this weird error on > Linux IA32 while compiling a C++ program. Should I update to 2.95? Since you only provide a code fragment, not a complete input, no one can tell whether or not 2.95 fixes the bug you are seeing. Also, you say "Linux IA32" but that wouldn't be enough info. There have been bugs with conditional move instructions (enabled only for i686, not for i586) in the past that have produced things like this. From gcc-return-8706-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 16:27:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5255 invoked by alias); 2 Aug 1999 16:27:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5248 invoked from network); 2 Aug 1999 16:27:39 -0000 Received: from sloxch02-ext.smg.seagatesoftware.com (HELO sloxch04.nsmg.seagatesoftware.com) (199.5.174.18) by egcs.cygnus.com with SMTP; 2 Aug 1999 16:27:39 -0000 Received: by sloxch04.nsmg.seagatesoftware.com with Internet Mail Service (5.5.2448.0) id ; Mon, 2 Aug 1999 09:26:09 -0700 Message-ID: <912B571D21A0D211B63100009484697A06D00F@sloxch04.nsmg.seagatesoftware.com> From: Tony Orling To: "'gcc@gcc.gnu.org'" Subject: GCC 2.95 builds on sparc-sun-solaris2.7 Date: Mon, 2 Aug 1999 09:26:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" No new problems encountered so far. Tony Orling mailto:tony.orling@veritas.com From gcc-return-8707-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 16:30:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6143 invoked by alias); 2 Aug 1999 16:30:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6135 invoked from network); 2 Aug 1999 16:30:47 -0000 Received: from dhcp41.moberg.com (207.8.227.41) by egcs.cygnus.com with SMTP; 2 Aug 1999 16:30:47 -0000 Received: (from george@localhost) by dhcp41.moberg.com (8.8.7/8.8.7) id MAA07826; Mon, 2 Aug 1999 12:33:28 -0400 Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199908021617.JAA01845@atrus.synopsys.com> Date: Mon, 02 Aug 1999 12:33:28 -0400 (EDT) Reply-To: george@moberg.com Organization: Moberg Research, Inc. From: george@moberg.com To: Joe Buck Subject: Re: Unrecognized insn internal error in egcs 1.1.2 Cc: gcc@gcc.gnu.org On 02-Aug-99 Joe Buck wrote: > >> OK, I'm pulling my hair out. 1.1.2 is giving me this weird error on >> Linux IA32 while compiling a C++ program. Should I update to 2.95? > > Since you only provide a code fragment, not a complete input, no one > can tell whether or not 2.95 fixes the bug you are seeing. Unfortunately the complete input is rather huge. I'll try to pare it down. Does all of this stuff spit out by the compiler (below) provide any clues? Does anyone have any idea exactly what this output means? TransformConnectionComponent.cpp: In method `void CTransformConnectionComponent::_OpenDataConnection(const char *, const char *)': TransformConnectionComponent.cpp:178: internal error--unrecognizable insn: (insn 284 624 286 (set (reg:SI 48) (mem/s:SI (plus:SI (mem:SI (reg:SI 88)) (const_int 12)))) -1 (insn_list 624 (nil)) (nil)) ../../egcs-1.1.2/gcc/toplev.c:1367: Internal compiler error in function fatal_insn > Also, you say "Linux IA32" but that wouldn't be enough info. There have > been bugs with conditional move instructions (enabled only for i686, > not for i586) in the past that have produced things like this. The compiler is running on a Pentium II. If you look at the command line, you'll notice that I don't explicitly set the architecture for which I'm compiling: eg_g++ -g -c -Wall -ansi -pedantic -D_DEBUG -I. -I/usr/local/libmrc/include -I../../common -Itransforms -D_GNU_SOURCE -D_REENTRANT -DPLATFORM_LINUX=1 -DEXPORT= -fno-implicit-templates -fnew-exceptions -fasynchronous-exceptions -fvtable-thunks -fexceptions TransformConnectionComponent.cpp -o TransformConnectionComponent.otd Am I getting i686 or i586 (or i486?) if I compiled egcs using its default compilation rules on a Pentium II machine? For the record, I get the error both with and without -g, and with and without -O2. --- George T. Talbot From gcc-return-8708-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 17:22:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13926 invoked by alias); 2 Aug 1999 17:22:31 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13901 invoked from network); 2 Aug 1999 17:22:29 -0000 Received: from mescaline.gnu.org (158.121.106.21) by egcs.cygnus.com with SMTP; 2 Aug 1999 17:22:29 -0000 Received: from hamachi.synopsys.com (hamachi.synopsys.com [204.176.20.26]) by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id NAA32086 for ; Mon, 2 Aug 1999 13:21:05 -0400 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id KAA24230; Mon, 2 Aug 1999 10:18:51 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id KAA08249; Mon, 2 Aug 1999 10:18:47 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id KAA03144; Mon, 2 Aug 1999 10:18:47 -0700 Message-Id: <199908021718.KAA03144@atrus.synopsys.com> Subject: Re: Unrecognized insn internal error in egcs 1.1.2 To: george@moberg.com Date: Mon, 2 Aug 99 10:18:47 PDT Cc: jbuck@synopsys.com, gcc@gcc.gnu.org In-Reply-To: ; from "george@moberg.com" at Aug 2, 99 12:33 pm X-Mailer: ELM [version 2.3 PL11] > >> OK, I'm pulling my hair out. 1.1.2 is giving me this weird error on > >> Linux IA32 while compiling a C++ program. Should I update to 2.95? > > > > Since you only provide a code fragment, not a complete input, no one > > can tell whether or not 2.95 fixes the bug you are seeing. > > Unfortunately the complete input is rather huge. I'll try to pare it down. Alternatively, you could build gcc 2.95 and try it. Otherwise there's no alternative than to send an example. > Does all of this stuff spit out by the compiler (below) provide any > clues? Does anyone have any idea exactly what this output means? The output means that, in the process of transforming your input, the compiler has produced a bit of RTL code that cannot be turned into any legal instruction. This is not supposed to ever happen, and indicates a compiler bug. Generally speaking, people are never going to be able to diagnose these just from a code fragment and an error message; such things may depend on the entire state of the compiler just before it reached this point. > Am I getting i686 or i586 (or i486?) if I compiled egcs using its default > compilation rules on a Pentium II machine? Type "gcc -v" and the compiler will tell you. From gcc-return-8709-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 17:49:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19000 invoked by alias); 2 Aug 1999 17:49:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18973 invoked from network); 2 Aug 1999 17:49:39 -0000 Received: from dhcp41.moberg.com (207.8.227.41) by egcs.cygnus.com with SMTP; 2 Aug 1999 17:49:39 -0000 Received: (from george@localhost) by dhcp41.moberg.com (8.8.7/8.8.7) id NAA08633; Mon, 2 Aug 1999 13:52:07 -0400 Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199908021718.KAA03144@atrus.synopsys.com> Date: Mon, 02 Aug 1999 13:52:07 -0400 (EDT) Reply-To: george@moberg.com Organization: Moberg Research, Inc. From: george@moberg.com To: Joe Buck Subject: Re: Unrecognized insn internal error in egcs 1.1.2 Cc: gcc@gcc.gnu.org On 02-Aug-99 Joe Buck wrote: >> >> OK, I'm pulling my hair out. 1.1.2 is giving me this weird error on >> >> Linux IA32 while compiling a C++ program. Should I update to 2.95? >> > >> > Since you only provide a code fragment, not a complete input, no one >> > can tell whether or not 2.95 fixes the bug you are seeing. >> >> Unfortunately the complete input is rather huge. I'll try to pare it down. > > Alternatively, you could build gcc 2.95 and try it. Otherwise there's > no alternative than to send an example. I'll give gcc 2.95 a try and see what happens. >> Does all of this stuff spit out by the compiler (below) provide any >> clues? Does anyone have any idea exactly what this output means? > > The output means that, in the process of transforming your input, the > compiler has produced a bit of RTL code that cannot be turned into > any legal instruction. This is not supposed to ever happen, and indicates > a compiler bug. Generally speaking, people are never going to be able > to diagnose these just from a code fragment and an error message; such > things may depend on the entire state of the compiler just before it > reached this point. If it doesn't work with 2.95, I'll try coming up with a whole program that does the same thing. >> Am I getting i686 or i586 (or i486?) if I compiled egcs using its default >> compilation rules on a Pentium II machine? > > Type "gcc -v" and the compiler will tell you. Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) How do I tell it to use i586? (for testing) --- George T. Talbot From gcc-return-8710-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 17:56:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20601 invoked by alias); 2 Aug 1999 17:55:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20586 invoked from network); 2 Aug 1999 17:55:50 -0000 Received: from dhcp41.moberg.com (207.8.227.41) by egcs.cygnus.com with SMTP; 2 Aug 1999 17:55:50 -0000 Received: (from george@localhost) by dhcp41.moberg.com (8.8.7/8.8.7) id NAA09299; Mon, 2 Aug 1999 13:58:36 -0400 Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199908021718.KAA03144@atrus.synopsys.com> Date: Mon, 02 Aug 1999 13:58:36 -0400 (EDT) Reply-To: george@moberg.com Organization: Moberg Research, Inc. From: george@moberg.com To: Joe Buck Subject: Re: Unrecognized insn internal error in egcs 1.1.2 Cc: gcc@gcc.gnu.org One other weird hint, if I remove the try { } and catch (...) {...}, then the program compiles. -G On 02-Aug-99 Joe Buck wrote: >> >> OK, I'm pulling my hair out. 1.1.2 is giving me this weird error on >> >> Linux IA32 while compiling a C++ program. Should I update to 2.95? >> > >> > Since you only provide a code fragment, not a complete input, no one >> > can tell whether or not 2.95 fixes the bug you are seeing. >> >> Unfortunately the complete input is rather huge. I'll try to pare it down. > > Alternatively, you could build gcc 2.95 and try it. Otherwise there's > no alternative than to send an example. > >> Does all of this stuff spit out by the compiler (below) provide any >> clues? Does anyone have any idea exactly what this output means? > > The output means that, in the process of transforming your input, the > compiler has produced a bit of RTL code that cannot be turned into > any legal instruction. This is not supposed to ever happen, and indicates > a compiler bug. Generally speaking, people are never going to be able > to diagnose these just from a code fragment and an error message; such > things may depend on the entire state of the compiler just before it > reached this point. > >> Am I getting i686 or i586 (or i486?) if I compiled egcs using its default >> compilation rules on a Pentium II machine? > > Type "gcc -v" and the compiler will tell you. --- George T. Talbot From gcc-return-8711-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 17:58:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21381 invoked by alias); 2 Aug 1999 17:58:18 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21362 invoked from network); 2 Aug 1999 17:58:16 -0000 Received: from dhcp41.moberg.com (207.8.227.41) by egcs.cygnus.com with SMTP; 2 Aug 1999 17:58:16 -0000 Received: (from george@localhost) by dhcp41.moberg.com (8.8.7/8.8.7) id OAA09437; Mon, 2 Aug 1999 14:01:02 -0400 Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199908021718.KAA03144@atrus.synopsys.com> Date: Mon, 02 Aug 1999 14:01:02 -0400 (EDT) Reply-To: george@moberg.com Organization: Moberg Research, Inc. From: george@moberg.com To: Joe Buck Subject: Re: Unrecognized insn internal error in egcs 1.1.2 Cc: gcc@gcc.gnu.org An even better hint is that if I remove only "delete pOutput;", it compiles successfully, with "throw;" still in there. --- George T. Talbot From gcc-return-8712-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 17:59:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21747 invoked by alias); 2 Aug 1999 17:59:24 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21738 invoked from network); 2 Aug 1999 17:59:23 -0000 Received: from dhcp41.moberg.com (207.8.227.41) by egcs.cygnus.com with SMTP; 2 Aug 1999 17:59:23 -0000 Received: (from george@localhost) by dhcp41.moberg.com (8.8.7/8.8.7) id OAA09440; Mon, 2 Aug 1999 14:02:11 -0400 Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199908021718.KAA03144@atrus.synopsys.com> Date: Mon, 02 Aug 1999 14:02:11 -0400 (EDT) Reply-To: george@moberg.com Organization: Moberg Research, Inc. From: george@moberg.com To: Joe Buck Subject: Re: Unrecognized insn internal error in egcs 1.1.2 Cc: gcc@gcc.gnu.org Last thing. It fails with -m386, -m486, -mpentium, and -mpentiumpro --- George T. Talbot From gcc-return-8713-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 18:31:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30418 invoked by alias); 2 Aug 1999 18:31:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30411 invoked from network); 2 Aug 1999 18:31:25 -0000 Received: from ksmail.seed.net.tw (139.175.10.15) by egcs.cygnus.com with SMTP; 2 Aug 1999 18:31:25 -0000 Received: from fastmail.jiahau.com.tw ([210.64.253.18]) by ksmail.seed.net.tw (8.9.2/8.9.1a) with ESMTP id CAA03937; Tue, 3 Aug 1999 02:27:44 +0800 (CST) Date: Tue, 3 Aug 1999 02:27:44 +0800 (CST) Received: from FASTMAIL/PQ1 by fastmail.jiahau.com.tw (Mercury 1.21); 29 Jul 98 03:30:01 +1100 Received: from PQ1 by FASTMAIL (Mercury 1.21); 29 Jul 98 02:24:01 +1100 Received: from localhost by fastmail.jiahau.com.tw (Mercury 1.21); 29 Jul 98 02:23:47 +1100 To: qeobeapi37@quintessenz.at From: qeobeapi37@quintessenz.at (Resopiu) Comments: Authenticated sender is Subject: Dream Vacation Getaway!! Win Florida/Cruise Sweepstakes !! Message-Id: <199908024242JAA3828@yhumils.jiahau.com.tw> CONGRATULATIONS! PACK YOUR BAGS! You have been Invited to ENTER the Florida/Cruise Getaway Sweepstakes ! ! ! This Dream Vacation WILL be given away. Will You be One of the Lucky Ones? You have been Invited to ENTER for a LIMITED TIME ONLY Click here *-**-*-*--**-*- *-**-*-*--**-*- *-**-*-*--**-*- For-list-removal, email littletike@bigfoot.com with the subject remove *-**-*-*--**-*- *-**-*-*--**-*- *-**-*- From gcc-return-8714-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 18:46:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32747 invoked by alias); 2 Aug 1999 18:46:24 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32739 invoked from network); 2 Aug 1999 18:46:23 -0000 Received: from mailgw.chips.ibm.com (192.91.197.8) by egcs.cygnus.com with SMTP; 2 Aug 1999 18:46:23 -0000 Received: from mailrelay.btv.ibm.com (mailrelay.btv.ibm.com [9.66.15.39]) by mailgw.chips.ibm.com (8.8.8/8.8.8) with ESMTP id OAA08200 for ; Mon, 2 Aug 1999 14:45:36 -0400 Received: from apache4.btv.ibm.com (apache4.btv.ibm.com [9.66.143.20]) by mailrelay.btv.ibm.com (8.8.8/8.8.8) with ESMTP id OAA143908 for ; Mon, 2 Aug 1999 14:45:15 -0400 Received: from apache4.btv.ibm.com (schuld@localhost) by apache4.btv.ibm.com (8.8.8/8.8.8) with ESMTP id OAA76956 for ; Mon, 2 Aug 1999 14:45:35 -0400 Message-Id: <199908021845.OAA76956@apache4.btv.ibm.com> X-Mailer: exmh version 2.0.3 3/23/99 To: gcc@gcc.gnu.org X-uri: http://www.chips.ibm.com/products/foundry/ X-Note-Format: RFC822 Subject: Build report for sparc-sun-sunos4.1.4 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Aug 1999 14:45:34 -0400 From: "David W. Schuler" I have successfully compiled gcc version 2.95 19990728 (release) for sparc-sun-sunos4.1.4. Counting all warnings, there are 31 warnings in stage3 of this bootstrap. Number of warnings per file: 6 ../../../gcc/gcc/f/com.c 4 ../../../gcc/gcc/f/bad.c 3 ../../../gcc/gcc/f/target.c 3 ../../../gcc/gcc/f/stw.c 3 ../../../gcc/gcc/f/storag.c 3 ../../../gcc/gcc/f/intrin.c 2 cxxmain.c 2 ../../../gcc/gcc/f/src.c 2 ../../../gcc/gcc/f/lex.c 1 ../../../gcc/gcc/f/where.c 1 ../../../gcc/gcc/f/stb.c 1 ../../../gcc/gcc/f/parse.c Number of warning types: 27 implicit declaration of function `???' 2 assignment discards qualifiers from pointer target type 1 unused parameter `???' 1 assignment from incompatible pointer type From gcc-return-8715-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 18:50:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1473 invoked by alias); 2 Aug 1999 18:50:28 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1465 invoked from network); 2 Aug 1999 18:50:26 -0000 Received: from ns1214.munich.netsurf.de (HELO fred.muc.de) (none@195.180.235.214) by egcs.cygnus.com with SMTP; 2 Aug 1999 18:50:26 -0000 Received: from andi by fred.muc.de with local (Exim 2.05 #1) id 11BMNM-0000Ut-00; Mon, 2 Aug 1999 19:59:52 +0200 To: jquinn@nortelnetworks.com (Jerry Quinn) cc: egcs@egcs.cygnus.com Subject: Re: Simple RTL question (was: New cfg code) References: <14245.45996.480771.600072@gargle.gargle.HOWL> <14245.48992.142999.156653@gargle.gargle.HOWL> From: Andi Kleen Date: 02 Aug 1999 19:59:52 +0200 In-Reply-To: jquinn@nortelnetworks.com's message of "2 Aug 1999 18:00:43 +0200" Message-ID: Lines: 18 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii jquinn@nortelnetworks.com (Jerry Quinn) writes: > > Bernd> All the rtl expressions are defined (and documented) in the rtl.def > Bernd> file. The section for CODE_LABEL is this: /* Holds a label that is > Bernd> followed by instructions. Operand: 3: is a number that is unique in > Bernd> the entire compilation. 4: is the user-given name of the label, if > Bernd> any. 5: is used in jump.c for the use-count of the label. 6: is used > Bernd> in flow.c to point to the chain of label_ref's to this label. */ > > OK, so the info docs are out of synch. If nobody else does, I'll submit an update. Would it be possible to generate those parts of rtl.texi mechanically from rtl.def (via a perl script or similar) ? -Andi -- This is like TV. I don't like TV. From gcc-return-8716-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 18:53:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2547 invoked by alias); 2 Aug 1999 18:53:30 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2530 invoked from network); 2 Aug 1999 18:53:25 -0000 Received: from 209-249-66-150.snj0.flashcom.net (HELO ocean.lucon.org) (postfix@209.249.66.150) by egcs.cygnus.com with SMTP; 2 Aug 1999 18:53:25 -0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 00C6C57BA; Mon, 2 Aug 1999 11:52:00 -0700 (PDT) Subject: binutils 2.9.5.0.4 is released. To: linux-gcc@vger.rutgers.edu (linuxgcc) Date: Mon, 2 Aug 1999 11:52:00 -0700 (PDT) Cc: egcs@egcs.cygnus.com, libc-hacker@sourceware.cygnus.com (GNU C Library), kjahds@kjahds.com (Kenneth Albanowski), lmfken@lmf.ericsson.se (Kenneth Osterberg), mat@lcs.mit.edu (Mat Hostetter), doughera@lafcol.lafayette.edu (Andy Dougherty), brian@mathworks.com (Brian Bourgault), imp@village.org (Warner Losh), meissner@cygnus.com (Michael Meissner), rfg@monkeys.com (Ron Guilmette), linux-binutils-in@polstra.com (John Polstra), galenh@micron.net (Galen Hazelwood), ralf@informatik.uni-koblenz.de (Ralf Baechle), linas@linas.org (Linas Vepstas), aries@hal2000.terra.vein.hu (Feher Janos) X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990802185200.00C6C57BA@ocean.lucon.org> From: hjl@lucon.org (H.J. Lu) This is the beta release of binutils 2.9.5.0.4 for Linux, which is based on binutils 1999 0801 plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. I merged a MIPS gas patch from binutils 2.9.1.0.25 to the current binutils and there are many changes in MIPS/ELF in bfd. I'd like to hear reports on Linux/MIPS. Please report any bugs related to binutils 2.9.5.0.4 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.5.0.4.tar.gz. Source code. 2. binutils-2.9.5.0.3-2.9.5.0.4.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.5.0.4-1.src.rpm. Source RPM. 4. binutils-2.9.5.0.4-1.i386.rpm. Binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 08/02/99 From gcc-return-8717-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 19:26:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8837 invoked by alias); 2 Aug 1999 19:26:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8823 invoked from network); 2 Aug 1999 19:26:12 -0000 Received: from server.splicenet.com.br (200.246.52.9) by egcs.cygnus.com with SMTP; 2 Aug 1999 19:26:12 -0000 Received: from anmendes (vot12.socsplicenet.com.br [200.231.64.78]) by server.splicenet.com.br (8.8.6/8.7.3) with SMTP id QAA09749 for ; Mon, 2 Aug 1999 16:27:50 -0300 (EST) Message-ID: <001901bedd1d$8d0297a0$4e40e7c8@anmendes> From: "Antonio Mendes de Oliveira Neto" To: Subject: successful build cross and native mingw32-gcc Date: Mon, 2 Aug 1999 16:30:57 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="x-user-defined" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 cross mingw32 ../configure --prefix=/usr/local/cross-mingw32 --host=i586-pc-linux-gnu --ta rget=i386-pc-mingw32 native mingw32 ../configure --prefix=/gcc-mingw32 --host=i386-pc-mingw32 --target=i386-pc-m ingw32 --build=i586-pc-linux-gnu thanks From gcc-return-8718-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 20:11:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16535 invoked by alias); 2 Aug 1999 20:11:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16525 invoked from network); 2 Aug 1999 20:11:35 -0000 Received: from tele-post-20.mail.demon.net (194.217.242.20) by egcs.cygnus.com with SMTP; 2 Aug 1999 20:11:35 -0000 Received: from cenderis.demon.co.uk ([193.237.0.193]) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 11BOQg-00036P-0K for gcc@gcc.gnu.org; Mon, 2 Aug 1999 20:11:28 +0000 Received: (from bruce@localhost) by cenderis.demon.co.uk (8.8.7/8.8.7) id TAA01557; Mon, 2 Aug 1999 19:30:30 +0100 To: gcc@gcc.gnu.org Subject: Re: New G++ Project References: <19990730234914J.mitchell@codesourcery.com> From: Bruce Stephens Date: 02 Aug 1999 19:30:30 +0100 In-Reply-To: Mark Mitchell's message of "Fri, 30 Jul 1999 23:49:14 -0700" Message-ID: Lines: 29 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mark Mitchell writes: [...] > We will also be documenting this representation and the API (i.e., > the various tree macros and functions) that can be used to access > the representation; this representation and the accompanying API > could be used by a variety of tools that are interested in C++ > source, such as debuggers, intelligent editors, and source browsers. > Although this work will be focused on the C++ front-end, we expect > that the C front-end will also be able to make use of the same > representation in the future. That's great news. By coincidence, I was just about to try again doing one subpart of this myself (specifically for source browsers), but it's obviously much better if someone else does it---especially someone that knows what they're doing with the code (which I don't). > -- > Mark Mitchell mark@codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com On another topic (which is slightly related), people may be interested to know that there may soon be alternatives to VCG for looking at graphs (not that there's anything particularly wrong with VCG, but a choice isn't bad). AT&T is in the process of releasing its graphviz software, , under some license conforming to some open source definition. (The license isn't there yet, but they're clearly working in the right direction.) From gcc-return-8719-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 20:23:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20921 invoked by alias); 2 Aug 1999 20:23:41 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20908 invoked by uid 9012); 2 Aug 1999 20:23:38 -0000 Message-ID: <19990802202337.20907.qmail@egcs.cygnus.com> From: korbb@egcs.cygnus.com Subject: New AutoGen To: egcs@egcs.cygnus.com, autogen@linuxbox.com Date: Mon, 2 Aug 1999 13:23:37 -0700 (PDT) Reply-To: "Bruce Korb" Content-Type: text I have installed a new autogen-4.5.5 in: ftp://sourceware.cygnus.com/pub/egcs/infrastructure/autogen.tar.gz ftp://autogen.linuxbox.com/pub/autogen-4.5.5.tar.gz The updated online docs can be found at: http://autogen.linuxbox.com/doc/autogen_toc.html The primary intent of this release is to improve portability. If the primary purpose you have AutoGen is to regenerate the fixincludes stuff, you don't _have_ to have it. But I sure would like to know that it works on all those weirdo boxes out there :-). The distribution size has jumped from 472K to 759K because it contains a complete re-implementation of the printf family of functions. There was no way around it. We tried. :-( Gary V. Vaughan implemented it and made it better, too :-). See: http://autogen.linuxbox.com/doc/autogen_117.html http://autogen.linuxbox.com/doc/autogen_118.html If anyone has problems, please let me know so I can fix it before making an announcement on FreshMeat. I hope to be ready to do that before LinuxWorld. Regards, Bruce From gcc-return-8720-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 20:41:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24596 invoked by alias); 2 Aug 1999 20:41:03 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24588 invoked from network); 2 Aug 1999 20:41:02 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 2 Aug 1999 20:41:02 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA08015; Mon, 2 Aug 1999 13:40:18 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id NAA23568; Mon, 2 Aug 1999 13:40:18 -0700 To: "Daniel Berlin" Cc: "Bruce Q Hammond" , Subject: Re: Contribution to egcs References: From: Jason Merrill Date: 02 Aug 1999 13:40:18 -0700 In-Reply-To: "Daniel Berlin"'s message of "Mon, 2 Aug 1999 08:19:48 -0400" Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Daniel Berlin writes: >> One thing that might help me to get started is finding docs on the DWARF2 >> spec / implemetation notes. Try ftp://download.intel.com/design/perftool/tis/pfmt11.pdf Jason From gcc-return-8721-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 20:49:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26929 invoked by alias); 2 Aug 1999 20:49:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26874 invoked from network); 2 Aug 1999 20:49:41 -0000 Received: from mwunix.mitre.org (128.29.154.1) by egcs.cygnus.com with SMTP; 2 Aug 1999 20:49:41 -0000 Received: from pogo.mitre.org (pogo.mitre.org [128.29.83.22]) by mwunix.mitre.org (8.9.3/8.9.3) with ESMTP id QAA28646 for ; Mon, 2 Aug 1999 16:48:14 -0400 (EDT) Received: (from klouis@localhost) by pogo.mitre.org (8.8.8+Sun/8.8.8) id QAA27550; Mon, 2 Aug 1999 16:45:58 -0400 (EDT) Date: Mon, 2 Aug 1999 16:45:58 -0400 (EDT) Message-Id: <199908022045.QAA27550@pogo.mitre.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gcc@gcc.gnu.org Subject: Compilation of GCC 2.95 X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Reply-To: klouis@mitre.org From: "Kurt F. Louis" I've successfully built and installed GCC 2.95 on an Intel Pentium machine running Solaris 2.6. The output from /config.guess is: i386-pc-solaris2.6 Kurt -- ----------------------------------------------------------------------------- Kurt F. Louis MS W518 Senior Simulation & Modeling Engineer Information Systems & Technology Div. Email: klouis@mitre.org The MITRE Corporation Voice: (703) 883-3324 (Reston/VMail) 1820 Dolley Madison Boulevard Voice: (703) 883-1227 (Westgate) McLean, VA 22102-3481 Fax : (703) 883-3343 ----------------------------------------------------------------------------- From gcc-return-8722-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 22:35:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11804 invoked by alias); 2 Aug 1999 22:35:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11795 invoked from network); 2 Aug 1999 22:35:34 -0000 Received: from mailhost.uni-koblenz.de (@141.26.64.1) by egcs.cygnus.com with SMTP; 2 Aug 1999 22:35:34 -0000 Received: from lappi.waldorf-gmbh.de (cacc-22.uni-koblenz.de [141.26.131.22]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id AAA17124 for ; Tue, 3 Aug 1999 00:35:21 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.9.3/8.9.3) id AAA29879; Tue, 3 Aug 1999 00:32:06 +0200 Date: Tue, 3 Aug 1999 00:31:31 +0200 From: Ralf Baechle To: "H.J. Lu" Cc: linuxgcc , egcs@egcs.cygnus.com, GNU C Library , Kenneth Albanowski , Kenneth Osterberg , Mat Hostetter , Andy Dougherty , Brian Bourgault , Warner Losh , Michael Meissner , Ron Guilmette , John Polstra , Galen Hazelwood , Linas Vepstas , Feher Janos , linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: binutils 2.9.5.0.4 is released. Message-ID: <19990803003131.D29290@uni-koblenz.de> References: <19990802185200.00C6C57BA@ocean.lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <19990802185200.00C6C57BA@ocean.lucon.org>; from H.J. Lu on Mon, Aug 02, 1999 at 11:52:00AM -0700 X-Accept-Language: de,en,fr On Mon, Aug 02, 1999 at 11:52:00AM -0700, H.J. Lu wrote: > This is the beta release of binutils 2.9.5.0.4 for Linux, which is > based on binutils 1999 0801 plus various changes. It is purely for > Linux, although it has been tested on Solaris/Sparc and Solaris/x86 > from time to time. > > I merged a MIPS gas patch from binutils 2.9.1.0.25 to the current > binutils and there are many changes in MIPS/ELF in bfd. I'd like to > hear reports on Linux/MIPS. MIPS users should continue to use the latest 2.8.1-based releases available from ftp.linux.sgi.com. All newer linker have heavy bugs which will result in linker crashes, bad kernels and more. I especially have to warn about the binutils from Cygnus' anonymous CVS. At this time the MIPS support in that binutils versions is undergoing heavy rewrite in order to support the N32 ABI and as a temporary side effect they are therefore currently completly unusable for Linux/MIPS. Ralf From gcc-return-8723-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 23:08:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18704 invoked by alias); 2 Aug 1999 23:08:00 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18678 invoked from network); 2 Aug 1999 23:07:57 -0000 Received: from mescaline.gnu.org (158.121.106.21) by egcs.cygnus.com with SMTP; 2 Aug 1999 23:07:57 -0000 Received: from cibalia.gkvk.hr (mail@cibalia.gkvk.hr [161.53.211.3]) by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id TAA01632 for ; Mon, 2 Aug 1999 19:07:32 -0400 Received: from joy by cibalia.gkvk.hr with local (Exim 2.05 #1 (Debian)) id 11BR5A-0003Vc-00; Tue, 3 Aug 1999 01:01:24 +0200 Date: Tue, 3 Aug 1999 01:01:23 +0200 From: Josip Rodin To: gcc@gcc.gnu.org Subject: successful gcc 2.95 build on a UnixWare 2.1.2 system Message-ID: <19990803010123.A13342@cibalia.gkvk.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Hi, Before even trying the new GCC on my Linux systems (because I know it would work there for sure :), I went to compile it on an UnixWare 2.1.2 machine, and it worked flawlessly! I later compiled wget and shellutils with it, and they appear to be working correctly. $ ./config.guess i386-pc-sysv4.2uw2.1.2 Congratulations and thousand thanks for such great software! -- enJoy -*/\*- don't even try to pronounce my first name From gcc-return-8724-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 02 23:28:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23985 invoked by alias); 2 Aug 1999 23:28:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23972 invoked from network); 2 Aug 1999 23:28:23 -0000 Received: from newton.math.purdue.edu (root@128.210.3.6) by egcs.cygnus.com with SMTP; 2 Aug 1999 23:28:23 -0000 Received: from polya.math.purdue.edu (lucier@polya.math.purdue.edu [128.210.3.194]) by newton.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.3) with ESMTP id SAA01852; Mon, 2 Aug 1999 18:26:59 -0500 (EST) Received: (from lucier@localhost) by polya.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.1) id SAA27664; Mon, 2 Aug 1999 18:26:58 -0500 (EST) Date: Mon, 2 Aug 1999 18:26:58 -0500 (EST) From: Brad Lucier Message-Id: <199908022326.SAA27664@polya.math.purdue.edu> To: gcc-bugs@gcc.gnu.org, gcc@gcc.gnu.org Subject: bug in testsuite FAQ entry? Cc: lucier@math.purdue.edu X-Sun-Charset: US-ASCII Is the online FAQ entry for how to run the testsuite with different flags accurate? I couldn't get anything to work in tcsh until I reversed the order of the two types of quotes: make RUNTESTFLAGS="--tool_opts '-mieee -mcpu=ev6'" check Brad Lucier lucier@math.purdue.edu From gcc-return-8725-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 01:02:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11251 invoked by alias); 3 Aug 1999 01:02:12 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11241 invoked from network); 3 Aug 1999 01:02:11 -0000 Received: from gwdu42.gwdg.de (HELO gwdu12.gwdg.de) (134.76.10.26) by egcs.cygnus.com with SMTP; 3 Aug 1999 01:02:11 -0000 Received: from ras23-147.gwdg.de ([134.76.23.147]) by gwdu12.gwdg.de with smtp (Exim 2.12 #1) id 11BSwe-0000B5-00; Tue, 3 Aug 1999 03:00:46 +0200 From: kthomas@gwdg.de (Philipp Thomas) To: Arvind Sankar Cc: gcc@gcc.gnu.org Subject: Re: On the RPM-spec (was: Re: gcc-2.95: Naming of the TAR file? GCC-2.95.tar.gz? gcc-2.95.tar.gz?) Date: Tue, 03 Aug 1999 01:00:39 GMT Message-ID: <37adf123.31861977@mailer.gwdg.de> References: <19990725110354.B14520@anjala.mit.edu> <99080111452700.00528@ns1102.munich.netsurf.de> <19990802014809.A18467@anjala.mit.edu> In-Reply-To: <19990802014809.A18467@anjala.mit.edu> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Mon, 2 Aug 1999 01:48:09 -0400, Arvind Sankar wrote: >And where would you build it otherwise? Like most of us build gcc, in a directory that's *not* part of the source tree. The procedure is very straight forward, just create the build dir and call the toplevel configure script from within that directory. If you look into the documentation, you will see, that this (i.e. objdir !=3D srcdir) is the recommended way to do it. Philipp --=20 You have moved your mouse. Windows must be rebooted for the changes to take effect. From gcc-return-8726-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 01:49:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16872 invoked by alias); 3 Aug 1999 01:49:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16865 invoked from network); 3 Aug 1999 01:49:32 -0000 Received: from anjala.mit.edu (root@18.251.3.144) by egcs.cygnus.com with SMTP; 3 Aug 1999 01:49:32 -0000 Received: (from arvind@localhost) by anjala.mit.edu (8.9.3/8.9.3) id VAA12176; Mon, 2 Aug 1999 21:47:27 -0400 X-Authentication-Warning: anjala.mit.edu: arvind set sender to arvinds@mit.edu using -f Date: Mon, 2 Aug 1999 21:47:27 -0400 From: Arvind Sankar To: Philipp Thomas Cc: Arvind Sankar , gcc@gcc.gnu.org Subject: Re: On the RPM-spec (was: Re: gcc-2.95: Naming of the TAR file? GCC-2.95.tar.gz? gcc-2.95.tar.gz?) Message-ID: <19990802214727.A12152@anjala.mit.edu> Reply-To: Arvind Sankar References: <19990725110354.B14520@anjala.mit.edu> <99080111452700.00528@ns1102.munich.netsurf.de> <19990802014809.A18467@anjala.mit.edu> <37adf123.31861977@mailer.gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6us In-Reply-To: <37adf123.31861977@mailer.gwdg.de>; from Philipp Thomas on Tue, Aug 03, 1999 at 01:00:39AM +0000 On Tue, Aug 03, 1999 at 01:00:39AM +0000, Philipp Thomas wrote: > On Mon, 2 Aug 1999 01:48:09 -0400, Arvind Sankar > wrote: > > >And where would you build it otherwise? > > Like most of us build gcc, in a directory that's *not* part of the > source tree. The procedure is very straight forward, just create the > build dir and call the toplevel configure script from within that > directory. If you look into the documentation, you will see, that this > (i.e. objdir != srcdir) is the recommended way to do it. I have seen the docs, yes. the pt is not with gcc, but with rpm. basically I build it inside srcdir/obj-{architecture}. gcc advises against this, but it works fine. with rpm, basically there arent too many directories outside the build directory where u can do stuff. I suppose one thing to do is to unpack inside BUILD/gcc-2.95/src and build in BUILD/gcc-2.95/obj, but this is not usually how .spec files are set up. -- arvind From gcc-return-8727-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 02:08:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19941 invoked by alias); 3 Aug 1999 02:07:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19916 invoked from network); 3 Aug 1999 02:07:40 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 3 Aug 1999 02:07:40 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id XAA17395; Mon, 2 Aug 1999 23:03:26 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id XAA29392; Mon, 2 Aug 1999 23:03:26 -0300 (EST) To: abel@bfr.co.il (Alexander L. Belikoff) Cc: egcs@egcs.cygnus.com Subject: Re: gcc-2.95 build FAILED! - RedHat Linux/Alpha 5.2 References: <30700.933551590@upchuck.cygnus.com> From: Alexandre Oliva Date: 02 Aug 1999 23:07:18 -0300 In-Reply-To: abel@bfr.co.il's message of "02 Aug 1999 00:03:12 +0300" Message-ID: Lines: 25 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 1, 1999, abel@bfr.co.il (Alexander L. Belikoff) wrote: > Jeffrey A Law writes: >> In message you write: >> > /tmp/cc2jzCeM.s:3711: Error: unknown opcode `sqrttsu' >> > /tmp/cc2jzCeM.s:3781: Error: unknown opcode `sqrttsu' >> Your assembler is out of date. Get a newer one. > But it was good enough three weeks ago, when gcc was in (apparent) > deep freeze! Was it on the very same host (i.e., was config.guess' output the same)? Maybe you get this opcode for alphaev56, but not for alphaev5 (this is just intended as an example) I could build gcc 2.95 on a RedHat 6.0/alpha (an AlphaStation 200), with binutils 2.9.1.0.24 (the one that ships with RH6.0), if this helps. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-8728-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 02:14:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22334 invoked by alias); 3 Aug 1999 02:14:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22290 invoked from network); 3 Aug 1999 02:14:30 -0000 Received: from edison.dialix.com.au (root@203.12.2.8) by egcs.cygnus.com with SMTP; 3 Aug 1999 02:14:30 -0000 Received: from prophecy.com.au (www.prophecy.com.au [203.12.2.244]) by edison.dialix.com.au (8.9.1/8.9.1/DIALixFlat) with ESMTP id MAA26904; Tue, 3 Aug 1999 12:14:19 +1000 (EST) (envelope-from brendan@dgs.monash.edu.au) Received: from dhcp20.prophecy.com.au ([203.21.127.60] helo=dgs.monash.edu.au) by prophecy.com.au with esmtp (Exim 3.02 #1) id 11BUD9-0004XW-00; Tue, 03 Aug 1999 12:21:51 +1000 Message-ID: <37A650C1.30AFAC2A@dgs.monash.edu.au> Date: Tue, 03 Aug 1999 12:15:30 +1000 From: Brendan Simon Reply-To: brendan@dgs.monash.edu.au Organization: CTAM Pty Ltd X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: egcs mailing list , binutils , gdb , newlib Subject: Sourceware synchronisation. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Now that the sourceware CD is available quarterly, I was wondering what the chances are of synchronising new releases of sourceware projects (binutils, gcc, newlib & gdb are the ones that mainly interest me. I'm not sure what else is on the sourceware CD as I do not have one yet). I would be nice to have the latest sourceware which have been synchronised with other sourceware releases. The definitions of "synchronise" is pretty open but I would like it to mean "tested and recommended". eg. The latest release of binutils, gcc, newlib and gdb that are recommended to work with each other with the least amount of building problems. I know this is a big ask and it is nearlyy impossible, but I think it might be worth some effort. Can various sourceware projects work together in some way. I'm sure there is some informal collaberation between projects but it is just a guess. Obviously this would only apply to projects that have some dependencies on other projects. Any thoughts, Brendan Simon. From gcc-return-8729-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 02:27:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24898 invoked by alias); 3 Aug 1999 02:27:05 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24876 invoked from network); 3 Aug 1999 02:27:04 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 3 Aug 1999 02:27:04 -0000 Received: from bugshack.cygnus.com (bugshack.cygnus.com [205.180.230.190]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id TAA03374; Mon, 2 Aug 1999 19:27:02 -0700 (PDT) Received: (jsm@localhost) by bugshack.cygnus.com (8.8.7/8.6.4) id TAA13864; Mon, 2 Aug 1999 19:27:02 -0700 Date: Mon, 2 Aug 1999 19:27:02 -0700 From: Jason Molenda To: Brendan Simon Cc: egcs mailing list , binutils , gdb , newlib Subject: Re: Sourceware synchronisation. Message-ID: <19990802192702.A13197@cygnus.com> References: <37A650C1.30AFAC2A@dgs.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <37A650C1.30AFAC2A@dgs.monash.edu.au>; from Brendan Simon on Tue, Aug 03, 1999 at 12:15:30PM +1000 EGCS (nee gcc), binutils, and GDB are all large projects and making a release involves a lot of work. I doubt any of us want to do it quarterly, and synchronizing our releases so they all happen at the same time is even more unlikely. The quarterly Sourceware CDs are not a compelling reason to release a new version of any of these programs. Just MHO, but "Not likely" is my first reaction to any proposal to try to attempt something like this. Development snapshots, on the other hand, should generally be pretty similar to each other (it may take a month or two for a change made to binutils to get merged over into the GDB repository, for instance) if you want to develop multiple things in an integrated setup. ------- As to the general topic of synchronizing shared files among these packages, changes are all propagated through Cygnus' internal CVS repository. e.g. someone makes a change to EGCS's libiberty; within a month or so, that change gets merged in to Cygnus' internal CVS repository, and then a month or so after that binutils has a merge with the Cygnus internal CVS repository and they pick up the change. If it's a critical change, it can be merged by hand by someone. GDB and newlib do not have external read/write repositories now, so they pick up the merged change right away and it should be reflected in their next snapshot. Jason Free the Software! From gcc-return-8730-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 03:52:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2452 invoked by alias); 3 Aug 1999 03:52:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2437 invoked from network); 3 Aug 1999 03:52:31 -0000 Received: from caip.rutgers.edu (128.6.236.10) by egcs.cygnus.com with SMTP; 3 Aug 1999 03:52:31 -0000 Received: (from ghazi@localhost) by caip.rutgers.edu (8.9.3/8.9.3) id XAA04147; Mon, 2 Aug 1999 23:52:27 -0400 (EDT) Date: Mon, 2 Aug 1999 23:52:27 -0400 (EDT) From: "Kaveh R. Ghazi" Message-Id: <199908030352.XAA04147@caip.rutgers.edu> To: gcc@gcc.gnu.org, schuld@btv.ibm.com Subject: Re: Build report for sparc-sun-sunos4.1.4 > From: "David W. Schuler" > > I have successfully compiled gcc version 2.95 19990728 (release) for > sparc-sun-sunos4.1.4. > > > Counting all warnings, > there are 31 warnings in stage3 of this bootstrap. > > Number of warnings per file: > 6 ../../../gcc/gcc/f/com.c > 4 ../../../gcc/gcc/f/bad.c > 3 ../../../gcc/gcc/f/target.c > 3 ../../../gcc/gcc/f/stw.c > 3 ../../../gcc/gcc/f/storag.c > 3 ../../../gcc/gcc/f/intrin.c > 2 cxxmain.c > 2 ../../../gcc/gcc/f/src.c > 2 ../../../gcc/gcc/f/lex.c > 1 ../../../gcc/gcc/f/where.c > 1 ../../../gcc/gcc/f/stb.c > 1 ../../../gcc/gcc/f/parse.c > > Number of warning types: > 27 implicit declaration of function `???' These warnings occur because SunOS4 didn't bother to provide most of the standard 'extern int' prototypes in its system headers. You can avoid these warnings by adding -D__USE_FIXED_PROTOTYPES__ to your BOOT_CFLAGS. > 2 assignment discards qualifiers from pointer target type This is a (harmless) missing `const' bug in libiberty/cplus-dem.c which is what gcc/cxxmain.c links to. > 1 unused parameter `???' Harmless. > 1 assignment from incompatible pointer type This is an oversight in the fixincludes process (both old and new) which has been present for years. Fixincludes failed to convert sunos4's stdlib.h from 'char* bsearch()' to 'void* bsearch()'. I've submitted a fix for it and hope to have it in the next release. --Kaveh -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions From gcc-return-8731-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 03:59:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3618 invoked by alias); 3 Aug 1999 03:59:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3602 invoked from network); 3 Aug 1999 03:59:53 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 3 Aug 1999 03:59:53 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id AAA18464; Tue, 3 Aug 1999 00:54:31 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id AAA07449; Tue, 3 Aug 1999 00:54:31 -0300 (EST) To: s1042080@u-aizu.ac.jp Cc: gcc@gcc.gnu.org Subject: Re: Installation of GCC-2.95 for IRIX5.3 References: <19990802133803M.s1042080@u-aizu.ac.jp> From: Alexandre Oliva Date: 03 Aug 1999 00:58:25 -0300 In-Reply-To: Masahito Yoshida's message of "Mon, 02 Aug 1999 13:38:03 +0900" Message-ID: Lines: 18 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 2, 1999, Masahito Yoshida wrote: > ./gcc/config/mips/iris5.h > 92:-32 -_SYSTYPE_SVR4 -rpath /usr/local/lib" The -rpath isn't necessarily a good idea. AFAIR, with IRIX's ld, only the last -rpath flag prevails, so this may potentially override user-specified -rpath flags, or be discarded because a user-specified -rpath flag appears after it. You may need something more elaborate, for example (untested, I'm not even sure $(rpath) works): ${!nostdlib:%{!rpath:-rpath /usr/local/lib} %{rpath:-rpath $(rpath):/usr/local/lib}} -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-8732-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 04:18:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6528 invoked by alias); 3 Aug 1999 04:18:19 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6477 invoked from network); 3 Aug 1999 04:18:15 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 3 Aug 1999 04:18:15 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id BAA18651; Tue, 3 Aug 1999 01:14:12 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id BAA09813; Tue, 3 Aug 1999 01:14:12 -0300 (EST) To: law@cygnus.com Cc: Richard Henderson , gcc@gcc.gnu.org, libtool@gnu.org Subject: Building a shared libgcc References: <32346.933580059@upchuck.cygnus.com> From: Alexandre Oliva Date: 03 Aug 1999 01:18:06 -0300 In-Reply-To: Jeffrey A Law's message of "Mon, 02 Aug 1999 01:47:39 -0600" Message-ID: Lines: 43 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 2, 1999, Jeffrey A Law wrote: > He [Jason] thinks we just have to bite the bullet and go with a > shared libgcc. Wow! That's cool, but what are we going to do to ensure that libgcc.so is found at run-time? One idea is to build libgcc (and the other run-time libs) with libtool, and arrange that (some subset or equivalent of) libtool is used to link with it. Unfortunately, the shell version of libtool is probably too slow for this, but the libtool team has considered rewriting libtool in C, to speed it up. We had given it up because it would require CC_FOR_BUILD when cross-compiling, but now that CC_FOR_BUILD is being somewhat standardized in autoconf, we could probably rely on it. It would be a pity to duplicate all of libtool in collect2... And it would be really nice if users could be provided with portable -R/-rpath switches, which we could easily accomplish with an integration of libtool into gcc/collect2. But then, maybe you'd rather just not worry about people who install GCC on directories other than /usr/lib or /usr/local/lib. I'd prefer to arrange that gcc ensures that it uses the libraries it builds, regardless of the installation prefix. > I stronly doubt we'll fix this for the gcc-2.95 minor releases, but > it would be good to fix it for the next major release. Do you see any drawback in the patch for DU that arranges that libgcc is fully copied into libstdc++, besides the fact that it might introduce binary compatibility problems if it was to be reverted? If this is the only problem with it, we could install it forever, given that it doesn't introduce any problem, and it fixes an IMHO serious existing problem. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-8733-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 04:18:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6745 invoked by alias); 3 Aug 1999 04:18:39 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6706 invoked from network); 3 Aug 1999 04:18:37 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 3 Aug 1999 04:18:36 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id WAA03492; Mon, 2 Aug 1999 22:16:32 -0600 X-Mailer: exmh version 2.0.2 To: Mumit Khan cc: gcc@gcc.gnu.org Subject: Re: link from www.gnu.org -> gcc.gnu.org Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 01 Aug 1999 01:23:51 CDT. <199908010623.BAA00927@mercury.xraylith.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Aug 1999 22:16:31 -0600 Message-ID: <3489.933653791@upchuck.cygnus.com> From: Jeffrey A Law In message <199908010623.BAA00927@mercury.xraylith.wisc.edu>you write: > Looking at http://www.gnu.org/software/gcc/, there is no obvious link > to gcc.gnu.org. I hope this discontinuity is fixed soon, since all > the real useful info is on gcc.gnu.org (such as the FAQ, build info > and so on). This link should prominently be featured in the News > section. > > The other nit is the pointer to vger.rutgers.edu as the snapshot > location, obviously a holdover from gcc-2.x days. We are still working through the details of how the web pages will work in the merged egcs/gcc world. Until we have a plan there will be a certain sense of disorganization in how the various web pages fit together and work. Sorry, jeff From gcc-return-8734-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 04:29:12 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9093 invoked by alias); 3 Aug 1999 04:29:11 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9077 invoked from network); 3 Aug 1999 04:29:09 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 3 Aug 1999 04:29:09 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id WAA03593; Mon, 2 Aug 1999 22:27:05 -0600 X-Mailer: exmh version 2.0.2 To: Alexandre Oliva cc: Richard Henderson , gcc@gcc.gnu.org, libtool@gnu.org Subject: Re: Building a shared libgcc Reply-To: law@cygnus.com In-reply-to: Your message of 03 Aug 1999 01:18:06 -0300. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Aug 1999 22:27:04 -0600 Message-ID: <3590.933654424@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > Wow! That's cool, but what are we going to do to ensure that > libgcc.so is found at run-time? It is one of the issues we will have to solve. > One idea is to build libgcc (and the other run-time libs) with > libtool, and arrange that (some subset or equivalent of) libtool is > used to link with it. I'd prefer not to have to fart around with libtool if we can help it; but ultimately we might have to. > Do you see any drawback in the patch for DU that arranges that libgcc > is fully copied into libstdc++, besides the fact that it might > introduce binary compatibility problems if it was to be reverted? If > this is the only problem with it, we could install it forever, given > that it doesn't introduce any problem, and it fixes an IMHO serious > existing problem. I don't want to mess with this. Please, let's not try to solve this problem, because no matter what we do, it's wrong. jeff From gcc-return-8735-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 04:54:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12652 invoked by alias); 3 Aug 1999 04:54:58 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12634 invoked from network); 3 Aug 1999 04:54:55 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 3 Aug 1999 04:54:55 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id WAA03773; Mon, 2 Aug 1999 22:52:36 -0600 X-Mailer: exmh version 2.0.2 To: Andi Kleen cc: jquinn@nortelnetworks.com (Jerry Quinn), egcs@egcs.cygnus.com Subject: Re: Simple RTL question (was: New cfg code) Reply-To: law@cygnus.com In-reply-to: Your message of 02 Aug 1999 19:59:52 +0200. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Aug 1999 22:52:36 -0600 Message-ID: <3770.933655956@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > Would it be possible to generate those parts of rtl.texi mechanically > from rtl.def (via a perl script or similar) ? It would be possible. However, in my experience, this does not actually work all that well. Just look at BFD which uses this kind of scheme. jeff From gcc-return-8736-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 05:19:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16081 invoked by alias); 3 Aug 1999 05:19:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16053 invoked from network); 3 Aug 1999 05:19:24 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 3 Aug 1999 05:19:24 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id CAA19358; Tue, 3 Aug 1999 02:15:21 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id CAA14915; Tue, 3 Aug 1999 02:15:23 -0300 (EST) To: law@cygnus.com Cc: Richard Henderson , gcc@gcc.gnu.org, libtool@gnu.org Subject: Re: Building a shared libgcc References: <3590.933654424@upchuck.cygnus.com> From: Alexandre Oliva Date: 03 Aug 1999 02:19:15 -0300 In-Reply-To: Jeffrey A Law's message of "Mon, 02 Aug 1999 22:27:04 -0600" Message-ID: Lines: 46 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 3, 1999, Jeffrey A Law wrote: >> One idea is to build libgcc (and the other run-time libs) with >> libtool, and arrange that (some subset or equivalent of) libtool is >> used to link with it. > I'd prefer not to have to fart around with libtool if we can help > it; but ultimately we might have to. Ouch!, that hurts! :-) I thought it would be ok to use libtool at least for the build, since libgcj does it already. Of course, gcc could get around libtool at run-time, by duplicating the hard-coding efforts, but just mopping under the carpet the problem of finding shared libraries at run-time, as we've been doing for libstdc++ for years, is not something we should do, IMHO, should we decide to build a shared libgcc. But maybe I'm just overestimating the number of people that enable shared libraries when building GCC *and* install it in non-standard locations. The fact that we don't get too many reports about this probably indicates that either people read the FAQ or that I'm overestimating it, but the fact that we *do* get some such reports indicates I'm not alone :-) WRT using libtool at run-time, for linking, it isn't currently feasible anyway; it will require some work on libtool to arrange that it can be used by gcc for linking, but I think it is a nice project, that is worth pursuing, at least for hacking value :-) Incidentally, it would be of much help for libtool to support multiple languages, because, instead of having to figure out by itself the command line options and libraries gcc passes to a linker, it would be able to get them straight from gcc. What do other libtool developers and users think? Should we reconsider implementing the C-compiled version of libtool? Would it be good for gcc to use it for linking? -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-8737-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 06:42:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27040 invoked by alias); 3 Aug 1999 06:42:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26989 invoked from network); 3 Aug 1999 06:42:29 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 3 Aug 1999 06:42:29 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id XAA12296; Mon, 2 Aug 1999 23:42:19 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id XAA27284; Mon, 2 Aug 1999 23:42:18 -0700 Date: Mon, 2 Aug 1999 23:42:18 -0700 From: Richard Henderson To: Alexandre Oliva Cc: "Alexander L. Belikoff" , egcs@egcs.cygnus.com Subject: Re: gcc-2.95 build FAILED! - RedHat Linux/Alpha 5.2 Message-ID: <19990802234218.B27193@cygnus.com> References: <30700.933551590@upchuck.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: ; from Alexandre Oliva on Mon, Aug 02, 1999 at 11:07:18PM -0300 On Mon, Aug 02, 1999 at 11:07:18PM -0300, Alexandre Oliva wrote: > Was it on the very same host (i.e., was config.guess' output the > same)? Maybe you get this opcode for alphaev56, but not for alphaev5 > (this is just intended as an example) The sqrt insn appears as of ev6. r~ From gcc-return-8738-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 06:45:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27728 invoked by alias); 3 Aug 1999 06:45:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27664 invoked from network); 3 Aug 1999 06:45:45 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 3 Aug 1999 06:45:45 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id XAA12508; Mon, 2 Aug 1999 23:45:34 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id XAA27289; Mon, 2 Aug 1999 23:45:34 -0700 Date: Mon, 2 Aug 1999 23:45:34 -0700 From: Richard Henderson To: Jeffrey A Law Cc: Bruce Q Hammond , egcs@egcs.cygnus.com Subject: Re: Contribution to egcs Message-ID: <19990802234534.C27193@cygnus.com> References: <30954.933556067@upchuck.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <30954.933556067@upchuck.cygnus.com>; from Jeffrey A Law on Sun, Aug 01, 1999 at 07:07:47PM -0600 On Sun, Aug 01, 1999 at 07:07:47PM -0600, Jeffrey A Law wrote: > First thing to check, are you getting redundant template instantiations > (is that the right term C++ folks?). If you are, that might explain why > your code is so big. It would also explain some of the huge bloat with your > debug symbols. > > I believe beos uses dwarf2 debug records, right? This is a known problem with dwarf2 support in binutils. The solution is to have the linker decompose and combine debug info common to different objects. r~ From gcc-return-8739-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 08:10:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5817 invoked by alias); 3 Aug 1999 08:10:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5802 invoked from network); 3 Aug 1999 08:10:50 -0000 Received: from proxy.typhoon.spb.ru (HELO intra.typhoon.spb.ru) (195.5.143.5) by egcs.cygnus.com with SMTP; 3 Aug 1999 08:10:50 -0000 Received: from localhost (proski@localhost) by intra.typhoon.spb.ru (8.9.3/8.8.7) with ESMTP id MAA10964; Tue, 3 Aug 1999 12:10:25 +0400 X-Authentication-Warning: intra.typhoon.spb.ru: proski owned process doing -bs Date: Tue, 3 Aug 1999 12:10:25 +0400 (EEST) From: Pavel Roskin X-Sender: pavel_roskin@intra.typhoon.spb.ru To: Alexandre Oliva cc: law@cygnus.com, Richard Henderson , gcc@gcc.gnu.org, libtool@gnu.org Subject: Re: Building a shared libgcc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello! > But maybe I'm just overestimating the number of people that enable > shared libraries when building GCC *and* install it in non-standard > locations. The fact that we don't get too many reports about this > probably indicates that either people read the FAQ or that I'm > overestimating it, but the fact that we *do* get some such reports > indicates I'm not alone :-) I install gcc in non-standard locations an all machines except those where I know the root password (where I use /usr/local unless /usr/bin/gcc in absolutely broken). I also install gcc in non-standard locations in gcc is a cross-compiler (it is usually /usr/local/hurd/ for the linux->hurd compiler and /mnt/gnu/usr/ for the cross-compiled hurd->hurd compiler) I'm usually careful enough to set LD_LIBRARY_PATH to an appropriate value. However, I realize that if by some reason LD_LIBRARY_PATH will not be set bad things will happen. This can happen if, for example, ssh is used to run programs compiled with a "private" (i.e. installed in a non-standard place) compiler. On systems where all programs are compiled by gcc, shared libgcc is as vital as shared libc. Installing libgcc in a non-standard place can cause a lot of problems. Maybe you should consider adding libgcc to libc. Then, on systems where libc includes the necessary routines you don't include them into libgcc. If all the necessary stuff can be found in libc, libgcc is not built. AFAIK, Libc CVS is now hosted by SourceWare, so it shouldn't be a problem to submit your changes. Another related issue is that I want to have full control on which libraries are linked as shared and which libraries are linked as static. I want something like --only-static=gcc --prefer-static=stdc++ --prefer-shared=Xm --only-shared=c Such options should not make "-l" options unnecessary. They should affect both explicitly and implicitly (e.g. libgcc.a) linked libraries. Pavel Roskin From gcc-return-8740-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 08:33:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8586 invoked by alias); 3 Aug 1999 08:33:07 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8568 invoked from network); 3 Aug 1999 08:33:02 -0000 Received: from smtp1.cern.ch (137.138.128.38) by egcs.cygnus.com with SMTP; 3 Aug 1999 08:33:02 -0000 Received: from pcep-jamie.cern.ch (pcep-jamie.cern.ch [137.138.38.126]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id KAA16311; Tue, 3 Aug 1999 10:32:58 +0200 (MET DST) Received: (from jamie@localhost) by pcep-jamie.cern.ch (8.9.3/8.9.3) id KAA29894; Tue, 3 Aug 1999 10:32:58 +0200 Date: Tue, 3 Aug 1999 10:32:58 +0200 From: Jamie Lokier To: Jeffrey A Law Cc: Andi Kleen , Jerry Quinn , egcs@egcs.cygnus.com Subject: Re: Simple RTL question (was: New cfg code) Message-ID: <19990803103258.C29844@pcep-jamie.cern.ch> References: <3770.933655956@upchuck.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <3770.933655956@upchuck.cygnus.com>; from Jeffrey A Law on Mon, Aug 02, 1999 at 10:52:36PM -0600 Jeffrey A Law wrote: > In message you write: > > Would it be possible to generate those parts of rtl.texi mechanically > > from rtl.def (via a perl script or similar) ? > It would be possible. > > However, in my experience, this does not actually work all that well. Just > look at BFD which uses this kind of scheme. Agree 100% on BFD. My (entirely theoretical ;-) approach to this sort of thing is to maintain docs and code together, and instead of mechanically generating the entire docs, _verify_ the docs instead. So if the docs are missing a field or function, the verifier script warns. Maybe it even inserts the missing function with "not yet documented". Sometimes a good doc string can be found with the thing to be documented, but sometimes it's good to write something separately, that better fits a manual. -- Jamie From gcc-return-8741-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 08:52:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11237 invoked by alias); 3 Aug 1999 08:52:37 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11212 invoked from network); 3 Aug 1999 08:52:36 -0000 Received: from web4.rocketmail.com (205.180.57.78) by egcs.cygnus.com with SMTP; 3 Aug 1999 08:52:36 -0000 Message-ID: <19990803085146.18700.rocketmail@web4.rocketmail.com> Received: from [193.243.161.92] by web4; Tue, 03 Aug 1999 01:51:46 PDT Date: Tue, 3 Aug 1999 01:51:46 -0700 (PDT) From: Martin Knoblauch Reply-To: knobi@knobisoft.de Subject: How to build dejagnu on alphaev6-dec-osf4.0e ? To: gcc@gcc.gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, probably not the most correct place to ask, but as it is gcc-2.95 related ... :-) Building gcc-2.95 on the alphaev6-dec-osf4.0e went apparently well until I tried to perform the "gmake check" step. Doing the boostrap process the first time on this platform, I fetched dejagnu-19990614 from the cygnus ftp server and built it. Besides some warnings about integer vs. pointer casts it went well. When I now do "gmake check" in the gcc-2.95 base directory, the following happens: - tests for libio and libstdc++ run OK, although warnings about "Unaligned Access" are displayed for the "expect" binary. The warnings maybe due to the int vs. pointer stuff, but don't seem to hurt to much. - all other tests (gcc, g++, objc) fail because: "ERROR: Couldn't find tool config file for unix". I looked at the README for dejagnu, but there was no special mentioning of the alpha platform. Any help is appreciated Martin === ------------------------------------------------------ Martin Knoblauch email: knobi@knobisoft.de or knobi@rocketmail.com www: http://www.knobisoft.de _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From gcc-return-8742-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 09:31:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16149 invoked by alias); 3 Aug 1999 09:31:08 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16113 invoked from network); 3 Aug 1999 09:31:00 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 3 Aug 1999 09:31:00 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id CAA16983; Tue, 3 Aug 1999 02:30:59 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id CAA27448; Tue, 3 Aug 1999 02:30:59 -0700 Date: Tue, 3 Aug 1999 02:30:59 -0700 From: Richard Henderson To: Jeffrey A Law Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: New cfg code Message-ID: <19990803023059.A27430@cygnus.com> References: <31298.933567296@upchuck.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <31298.933567296@upchuck.cygnus.com>; from Jeffrey A Law on Sun, Aug 01, 1999 at 10:14:56PM -0600 On Sun, Aug 01, 1999 at 10:14:56PM -0600, Jeffrey A Law wrote: > Which as far as I can tell has the effect of leaving the CODE_LABEL and > ADDR_VEC in no-mans land (ie, not in any basic block). That's correct. It isn't code that's executed -- it's data. Therefore it doesn't belong in the CFG proper. > One thought would be to try and have CSE kill the ADDR_VEC when it turns > the tablejump into a simple jump. > > Another would be to have jump kill the unreachable ADDR_VEC. > > Another would be to not special case this stuff in find_basic_blocks_1 and > instead either attach the insns to the previous block via merge_blocks or > delete the block if we determine it is unreachable. Nr 2 is my preferred short-term solution. Long term, of course, we've got to get rid of ADDR_VEC as an instruction completely. Probably by hanging a SEQUENCE containing the interesting label and ADDR_VEC off of a reg note on the tablejump insn. Nr 1 pollutes CSE with stuff it shouldn't be having to think about. Nr 3 results in uglier CFGs. Attached is a patch that allows the test to succeed. It's not as friendly as it might be, as optimization phase sequencing leaves the (code_label 80) around much longer than I would have liked. It is gone before final though, so it's not the end of the world. r~ * jump.c (delete_insn): Delete the addr_vec when deleting a tablejump. Index: jump.c =================================================================== RCS file: /egcs/carton/cvsfiles/egcs/gcc/jump.c,v retrieving revision 1.62 diff -c -p -d -r1.62 jump.c *** jump.c 1999/06/27 02:39:42 1.62 --- jump.c 1999/08/03 09:19:14 *************** delete_insn (insn) *** 4017,4036 **** and delete the label if it is now unused. */ if (GET_CODE (insn) == JUMP_INSN && JUMP_LABEL (insn)) ! if (--LABEL_NUSES (JUMP_LABEL (insn)) == 0) ! { ! /* This can delete NEXT or PREV, ! either directly if NEXT is JUMP_LABEL (INSN), ! or indirectly through more levels of jumps. */ ! delete_insn (JUMP_LABEL (insn)); ! /* I feel a little doubtful about this loop, ! but I see no clean and sure alternative way ! to find the first insn after INSN that is not now deleted. ! I hope this works. */ ! while (next && INSN_DELETED_P (next)) ! next = NEXT_INSN (next); ! return next; ! } /* Likewise if we're deleting a dispatch table. */ --- 4017,4052 ---- and delete the label if it is now unused. */ if (GET_CODE (insn) == JUMP_INSN && JUMP_LABEL (insn)) ! { ! rtx lab = JUMP_LABEL (insn), lab_next; ! ! if (--LABEL_NUSES (lab) == 0) ! { ! /* This can delete NEXT or PREV, ! either directly if NEXT is JUMP_LABEL (INSN), ! or indirectly through more levels of jumps. */ ! delete_insn (lab); ! ! /* I feel a little doubtful about this loop, ! but I see no clean and sure alternative way ! to find the first insn after INSN that is not now deleted. ! I hope this works. */ ! while (next && INSN_DELETED_P (next)) ! next = NEXT_INSN (next); ! return next; ! } ! else if ((lab_next = next_nonnote_insn (lab)) != NULL ! && GET_CODE (lab_next) == JUMP_INSN ! && (GET_CODE (PATTERN (lab_next)) == ADDR_VEC ! || GET_CODE (PATTERN (lab_next)) == ADDR_DIFF_VEC)) ! { ! /* If we're deleting the tablejump, delete the dispatch table. ! We may not be able to kill the label immediately preceeding ! just yet, as it might be referenced in code leading up to ! the tablejump. */ ! delete_insn (lab_next); ! } ! } /* Likewise if we're deleting a dispatch table. */ From gcc-return-8743-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 09:48:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22020 invoked by alias); 3 Aug 1999 09:48:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21976 invoked from network); 3 Aug 1999 09:47:33 -0000 Received: from firewall.mindmaker.hu (194.152.134.8) by egcs.cygnus.com with SMTP; 3 Aug 1999 09:47:33 -0000 Received: (qmail 6202 invoked from network); 3 Aug 1999 09:46:42 -0000 Received: from garfield.inside (HELO mindmaker.hu) (192.168.1.125) by firewall.inside with SMTP; 3 Aug 1999 09:46:42 -0000 Message-ID: <37A6BA83.8EF1F0FF@mindmaker.hu> Date: Tue, 03 Aug 1999 11:46:43 +0200 From: Levente Farkas Reply-To: lfarkas@mindmaker.hu Organization: Mindmaker Ltd. X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: hu,en MIME-Version: 1.0 To: gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: inner class in template class Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, is it a correct code or just the compilers can understand me ?: (the intresting part are in comment:-)) --------- #include using namespace std; template class A { public: class B { public: T i; }; T j; }; /* template > inline basic_ostream & __cdecl operator<<(basic_ostream & stream, const A::B & b) { return stream << b.i; } template ostream& operator<<(ostream& stream, const A::B & b) { return stream << b.i; } */ ostream& operator<<(ostream& stream, const A::B & b) { return stream << b.i; } void main() { A::B b; cout << b; } --------- -- Levente From gcc-return-8744-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 10:40:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28780 invoked by alias); 3 Aug 1999 10:40:22 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28746 invoked from network); 3 Aug 1999 10:39:41 -0000 Received: from fsuj20.rz.uni-jena.de (141.35.1.18) by egcs.cygnus.com with SMTP; 3 Aug 1999 10:39:41 -0000 Received: from biomag.uni-jena.de (stendal.biomag.uni-jena.de [141.35.200.65]) by fsuj20.rz.uni-jena.de (8.9.1a/8.9.1) with SMTP id MAA00889 for ; Tue, 3 Aug 1999 12:39:12 +0200 (MET DST) Received: by biomag.uni-jena.de (SMI-8.6/SMI-SVR4) id MAA22024; Tue, 3 Aug 1999 12:39:06 +0200 Date: Tue, 3 Aug 1999 12:39:06 +0200 From: fieseler@biomag.uni-jena.de (Thomas Fieseler) Message-Id: <199908031039.MAA22024@biomag.uni-jena.de> To: gcc@gcc.gnu.org Subject: build status Dear GCC-Gurus, gcc-2.95 compiled successfully on i486-pc-linux-gnu and everything seems to work fine. Cheers, Tom From gcc-return-8745-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 11:30:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3386 invoked by alias); 3 Aug 1999 11:30:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3356 invoked from network); 3 Aug 1999 11:30:51 -0000 Received: from gate3.eds.co.uk (205.191.194.194) by egcs.cygnus.com with SMTP; 3 Aug 1999 11:30:51 -0000 Received: (from smap@localhost) by gate3.eds.co.uk (8.8.5/8.8.5) id NAA17712 for ; Tue, 3 Aug 1999 13:24:25 +0200 From: olaf.wasmuth@europe.eds.com Received: from relay3a.cyberlink.eds.com(192.168.5.2) by gate3.eds.co.uk via smap (V2.1) id xmaa17671; Tue, 3 Aug 99 13:24:00 +0200 Received: (from smap@localhost) by relay3.cyberlink.eds.com (8.8.5/8.8.5) id NAA25260 for ; Tue, 3 Aug 1999 13:23:59 +0200 Received: from es160347.ws.ru.de.eds.com(134.46.99.73) by relay3.cyberlink.eds.com via smap (V2.1) id xma025234; Tue, 3 Aug 99 13:23:33 +0200 Received: by derumg01.cyberlink.eds.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 412567C2.00440D61 ; Tue, 3 Aug 1999 14:23:18 +0200 X-Lotus-FromDomain: EDSEUROPE@EDSHUBEUROPE@GMRUESSELSHEIM@DERUSMTP @GMRUESSELSHEIM@EDSHUBEUROPE To: gcc@gcc.gnu.org Message-ID: Date: Tue, 3 Aug 1999 13:18:28 +0100 Subject: Successfully built and installed GCC on HPUX-10.20 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Output from running srcdir/config.guess: hppa1.1-hp-hpux10.20 Regards, Olaf Wasmuth From gcc-return-8746-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 11:30:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3389 invoked by alias); 3 Aug 1999 11:30:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3365 invoked from network); 3 Aug 1999 11:30:53 -0000 Received: from gate3.eds.co.uk (205.191.194.194) by egcs.cygnus.com with SMTP; 3 Aug 1999 11:30:53 -0000 Received: (from smap@localhost) by gate3.eds.co.uk (8.8.5/8.8.5) id NAA17827 for ; Tue, 3 Aug 1999 13:24:45 +0200 From: olaf.wasmuth@europe.eds.com Received: from relay3a.cyberlink.eds.com(192.168.5.2) by gate3.eds.co.uk via smap (V2.1) id xma017695; Tue, 3 Aug 99 13:24:19 +0200 Received: (from smap@localhost) by relay3.cyberlink.eds.com (8.8.5/8.8.5) id NAA25386 for ; Tue, 3 Aug 1999 13:24:19 +0200 Received: from es160347.ws.ru.de.eds.com(134.46.99.73) by relay3.cyberlink.eds.com via smap (V2.1) id xmaf25236; Tue, 3 Aug 99 13:23:52 +0200 Received: by derumg01.cyberlink.eds.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 412567C2.00440F13 ; Tue, 3 Aug 1999 14:23:23 +0200 X-Lotus-FromDomain: EDSEUROPE@EDSHUBEUROPE@GMRUESSELSHEIM@DERUSMTP @GMRUESSELSHEIM@EDSHUBEUROPE To: gcc@gcc.gnu.org Message-ID: Date: Tue, 3 Aug 1999 13:19:16 +0100 Subject: Successfully built and installed GCC-2.95 on HPUX-10.20 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Output from running srcdir/config.guess: hppa1.1-hp-hpux10.20 Regards, Olaf Wasmuth From gcc-return-8747-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 12:07:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10519 invoked by alias); 3 Aug 1999 12:07:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10438 invoked from network); 3 Aug 1999 12:07:37 -0000 Received: from morannon.bfr.co.il (HELO buster.bfr.co.il) (root@192.116.142.129) by egcs.cygnus.com with SMTP; 3 Aug 1999 12:07:37 -0000 Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id PAA17176 for ; Tue, 3 Aug 1999 15:07:28 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.9.3/8.8.5) id LAA05752; Tue, 3 Aug 1999 11:50:37 +0300 To: egcs@egcs.cygnus.com Subject: Re: gcc-2.95 build FAILED! - RedHat Linux/Alpha 5.2 References: <30700.933551590@upchuck.cygnus.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: abel@bfr.co.il (Alexander L. Belikoff) Date: 03 Aug 1999 11:50:36 +0300 In-Reply-To: Alexandre Oliva's message of "02 Aug 1999 23:07:18 -0300" Message-ID: Lines: 26 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Alexandre Oliva writes: > On Aug 1, 1999, abel@bfr.co.il (Alexander L. Belikoff) wrote: > > > Jeffrey A Law writes: > >> In message you write: > >> > /tmp/cc2jzCeM.s:3711: Error: unknown opcode `sqrttsu' > >> > /tmp/cc2jzCeM.s:3781: Error: unknown opcode `sqrttsu' > > >> Your assembler is out of date. Get a newer one. > > > But it was good enough three weeks ago, when gcc was in (apparent) > > deep freeze! > > Was it on the very same host (i.e., was config.guess' output the > same)? Maybe you get this opcode for alphaev56, but not for alphaev5 > (this is just intended as an example) /usr/local/egcs.new/bin/gcc -v Reading specs from /usr/local/egcs.new/lib/gcc-lib/alphaev6-unknown-linux-gnu/2.95/specs gcc version 2.95 19990712 (prerelease) -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@vallinor4.com, abel@bfr.co.il From gcc-return-8748-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 12:17:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20944 invoked by alias); 3 Aug 1999 12:17:03 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20771 invoked from network); 3 Aug 1999 12:16:56 -0000 Received: from thunder.nws.noaa.gov (140.90.24.87) by egcs.cygnus.com with SMTP; 3 Aug 1999 12:16:56 -0000 Received: from thunder.nws.noaa.gov (ws8-nhdw [140.90.90.193]) by thunder.nws.noaa.gov (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA09360 for ; Tue, 3 Aug 1999 12:16:44 GMT Message-ID: <37A6DDAC.520BE17A@thunder.nws.noaa.gov> Date: Tue, 03 Aug 1999 12:16:44 +0000 From: George Trojan X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/770) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: successful (?) build on hp-ux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, After a third try, I managed to build egcs-2.95 on hp-ux (hppa1.1-hp-hpux10.20). I had to specify full path to gnu as: #!/bin/sh # configure.gt ../gcc-2.95/configure --prefix=/opt3/egcs --enable-shared \ --with-as=/usr/local/egcs/bin/as I had PATH with /usr/local/egcs/bin at the front and tried configure --with-gnu-as This did not work. It appears there is a bug (egcs or STL). I cannot compile the following snippet: // sin.c #include class S { public: typedef int (S::*pf)(); int foo(); int bar(); vector d_pf; }; int main() { S s; return 0; } g++ -v sin.c Reading specs from /opt3/egcs/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.95/specs gcc version 2.95 19990728 (release) /opt3/egcs/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.95/cpp -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -Dhppa -Dhp9000s800 -D__hp9000s80 0 -Dhp9k8 -DPWB -Dhpux -Dunix -D__hppa__ -D__hp9000s800__ -D__hp9000s800 -D__hp9 k8__ -D__PWB__ -D__hpux__ -D__unix__ -D__hppa -D__hp9000s800 -D__hp9k8 -D__PWB - D__hpux -D__unix -Asystem(unix) -Asystem(hpux) -Acpu(hppa) -Amachine(hppa) -D__E XCEPTIONS -D__hp9000s700 -D_PA_RISC1_1 -D_HPUX_SOURCE -D_HIUX_SOURCE sin.c /var/ tmp/ccVNw8Zt.ii GNU CPP version 2.95 19990728 (release) (hppa) #include "..." search starts here: #include <...> search starts here: /opt3/egcs/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.95/../../../../include/g++-3 /opt3/egcs/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.95/../../../../hppa1.1-hp-hpux10. 20/include /opt3/egcs/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.95/include /usr/include End of search list. The following default directories have been omitted from the search path: /usr/local/include End of omitted list. /opt3/egcs/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.95/cc1plus /var/tmp/ccVNw8Zt.ii - quiet -dumpbase sin.cc -version -o /var/tmp/ccalQeEm.s GNU C++ version 2.95 19990728 (release) (hppa1.1-hp-hpux10.20) compiled by GNU C version 2.95 19990728 (release). /opt3/egcs/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.95/../../../../include/g++-3/stl_a lloc.h: In instantiation of `allocator': sin.c:15: instantiated from here /opt3/egcs/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.95/../../../../include/g++-3/stl_a lloc.h:750: `allocator::address(int (S::* &)()) const' has already been declared in `allocator' I did submit a bug report. For the time being I have to revert back to egcs-2.91 : (. I don't want to redesign my code. George Trojan From gcc-return-8749-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 12:44:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3607 invoked by alias); 3 Aug 1999 12:44:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2214 invoked from network); 3 Aug 1999 12:43:43 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by egcs.cygnus.com with SMTP; 3 Aug 1999 12:43:43 -0000 Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x2.nokia.com (8.9.3/8.9.3) with ESMTP id PAA01680 for ; Tue, 3 Aug 1999 15:42:56 +0300 (EETDST) Received: from stybba.ntc.nokia.com (stybba.ntc.nokia.com [131.228.178.21]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id PAA21156 for ; Tue, 3 Aug 1999 15:42:34 +0300 (EETDST) Received: from anvil.ntc.nokia.com (girod@anvil.ntc.nokia.com [131.228.178.39]) by stybba.ntc.nokia.com (8.9.1a/8.9.1/Goodi) with ESMTP id PAA10534; Tue, 3 Aug 1999 15:42:32 +0300 (EET DST) Received: (from girod@localhost) by anvil.ntc.nokia.com (8.8.6 (PHNE_14041)/8.7.1) id PAA21808; Tue, 3 Aug 1999 15:42:31 +0300 (EETDST) Date: Tue, 3 Aug 1999 15:42:31 +0300 (EETDST) Message-Id: <199908031242.PAA21808@anvil.ntc.nokia.com> X-Authentication-Warning: anvil.ntc.nokia.com: girod set sender to girod@shire.ntc.nokia.com using -f From: Marc Girod To: gcc@gcc.gnu.org Subject: gcc 2.95 on HP-UX 10.20: -g ? X-Attribution: MGi Reply-to: Marc Girod User-Agent: SEMI/1.13.4 (Terai) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) Emacs/20.3.9 (hppa1.1-hp-hpux10.20) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Hello! I successfully installed gcc on hppa2.0-hp-hpux10.20. As explained in install/specific.html, I got a failure to "make bootstrap" and completed using "make all". BTW, the latest sed patch we have is: PHCO_18575 B.10.00.00.AA sed(1) cumulative patch. presumably newer than PHCO_15468. After this, I made a new build directory, and set up a soft link to gnu as in the first directory listed by: gcc -print-search-dirs | grep programs: This is what I had done with egcs 1.1.2. The version of as is from binutils-2.9.1. I configured and successfully built there with "make bootstrap", without a "-g option disabled." warning. However, compiling with the resulting gcc still doesn't support debugging. What did I do wrong? For the record, -ldce is still required even for building single threaded code. Best Regards! Marc -- Marc Girod Hiomo 5/1 Voice: +358-9-511 23746 Nokia Telecommunications P.O. Box 320 Mobile: +358-40-569 7954 NWS/NMS/NMS for Data 00045 NOKIA Group Fax: +358-9-511 23580 Finland girod@shire.ntc.nokia.com From gcc-return-8750-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 12:52:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7593 invoked by alias); 3 Aug 1999 12:52:05 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7576 invoked from network); 3 Aug 1999 12:52:01 -0000 Received: from mailgw.chips.ibm.com (192.91.197.8) by egcs.cygnus.com with SMTP; 3 Aug 1999 12:52:01 -0000 Received: from mailrelay.btv.ibm.com (mailrelay.btv.ibm.com [9.66.15.39]) by mailgw.chips.ibm.com (8.8.8/8.8.8) with ESMTP id IAA18972 for ; Tue, 3 Aug 1999 08:51:59 -0400 Received: from apache4.btv.ibm.com (apache4.btv.ibm.com [9.66.143.20]) by mailrelay.btv.ibm.com (8.8.8/8.8.8) with ESMTP id IAA70930 for ; Tue, 3 Aug 1999 08:51:38 -0400 Received: from apache4.btv.ibm.com (schuld@localhost) by apache4.btv.ibm.com (8.8.8/8.8.8) with ESMTP id IAA74358 for ; Tue, 3 Aug 1999 08:51:58 -0400 Message-Id: <199908031251.IAA74358@apache4.btv.ibm.com> X-Mailer: exmh version 2.0.3 3/23/99 To: gcc@gcc.gnu.org X-uri: http://www.chips.ibm.com/products/foundry/ X-Note-Format: RFC822 Subject: Build report for rs6000-ibm-aix4.1.5.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Aug 1999 08:51:58 -0400 From: "David W. Schuler" I have successfully compiled gcc version 2.95 19990728 (release) for rs6000-ibm-aix4.1.5.0. Counting all warnings, there are 3 warnings in stage3 of this bootstrap. Number of warnings per file: 2 cxxmain.c 1 ../../../gcc/gcc/f/com.c Number of warning types: 2 assignment discards qualifiers from pointer target type 1 unused parameter `???' From gcc-return-8751-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 13:02:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9128 invoked by alias); 3 Aug 1999 13:02:32 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9106 invoked from network); 3 Aug 1999 13:02:29 -0000 Received: from remote1.oarcorp.com (HELO oar3remote.oarcorp.com) (208.166.120.97) by egcs.cygnus.com with SMTP; 3 Aug 1999 13:02:29 -0000 Received: from localhost (joel@localhost) by oar3remote.oarcorp.com (8.8.7/8.8.7) with ESMTP id IAA17102 for ; Tue, 3 Aug 1999 08:04:22 -0500 Date: Tue, 3 Aug 1999 08:04:22 -0500 (CDT) From: X-Sender: joel@oar3remote To: egcs@sourceware.cygnus.com Subject: gcc 2.95 i960 question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, In building all the RTEMS targets, I came across this message while building the gcc support libraries: dp-bit cc1: warning: The -mlong-double-64 option does not work yet. xp-bit cc1: warning: The -mlong-double-64 option does not work yet. Is this something not setup right in the i960-rtems target or is this just an embedded multilib option that has been turned on before its time? --joel Joel Sherrill, Ph.D. Director of Research & Development joel@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 From gcc-return-8752-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 13:12:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12217 invoked by alias); 3 Aug 1999 13:12:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12176 invoked from network); 3 Aug 1999 13:12:43 -0000 Received: from mail.cmi.itds.com (HELO cliff.cmi.itds.com) (208.237.165.36) by egcs.cygnus.com with SMTP; 3 Aug 1999 13:12:43 -0000 Received: from vortex.cmi.itds.com (vortex.cmi.itds.com [208.237.164.80]) by cliff.cmi.itds.com (8.8.7/8.8.7) with ESMTP id IAA29678 for ; Tue, 3 Aug 1999 08:13:42 -0500 Received: (from spamment@localhost) by vortex.cmi.itds.com (8.8.6 (sendmail_886_v2)/8.8.6) id IAA13822; Tue, 3 Aug 1999 08:12:37 -0500 (CDT) Date: Tue, 3 Aug 1999 08:12:37 -0500 (CDT) Message-Id: <199908031312.IAA13822@vortex.cmi.itds.com> From: Simon Pamment To: gcc@gcc.gnu.org Subject: Successfully built and installed GCC on HPUX-10.20 and HP-UX 11.00 Mailer: Emacs [19.34] Reply-to: spamment@itds.com Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII Output from config.guess: hppa2.0-hp-hpux10.20 hppa1.1-hp-hpux11.00 ... Simon ... =============================================================================== Simon Pamment ITDS Voice : (217) 239-2482 2109 South Fox Drive Fax : (217) 351-7420 Champaign, Illinois mailto:spamment@itds.com 61824-0770 =============================================================================== From gcc-return-8753-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 14:32:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21853 invoked by alias); 3 Aug 1999 14:31:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21838 invoked from network); 3 Aug 1999 14:31:50 -0000 Received: from unknown (HELO xinter.frec.bull.fr) (192.90.72.8) by egcs.cygnus.com with SMTP; 3 Aug 1999 14:31:50 -0000 Received: from isabelle.frec.bull.fr ([129.183.89.2]) by xinter.frec.bull.fr (Netscape Messaging Server 3.6) with ESMTP id AAA25CE for ; Tue, 3 Aug 1999 15:11:36 +0200 Date: Tue, 3 Aug 1999 14:12:46 +0200 (DFT) From: Ciaran.Deignan@bull.net X-Sender: deignan@isabelle.frec.bull.fr To: gcc@gcc.gnu.org cc: David Edelsohn Subject: GCC-2.95 on AIX-4.3.2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Tue, 3 Aug 1999 16:31:45 +0200 (DFT) ReSent-From: Ciaran_Deignan ReSent-To: gcc@gcc.gnu.org ReSent-Subject: GCC-2.95 on AIX-4.3.2 ReSent-Message-ID: As per. install/FINALINSTALL... I sucessfully compiled and installed the "gcc-2.95.tar.bz2" distribution on an AIX 4.3.2 machine (config.guess says it a "powerpc-ibm-aix4.3.2.0"). I haven't tried using it yet... I am in the process of building a binary distribution that I will put on the site http://www-frec.bull.com/ (one big LPP containing everything, I don't understand the internal structure well enough to break it up...) Bye Ciaran +-------------------------------------------------------------------------+ Ciaran Deignan Tel: (France) 04 76 29 79 92 BULL XS-BU (http://www-frec.bull.com) HA and Consolidation Mail to: Ciaran.Deignan@bull.net Bullcom: 229 79 92 PGP: B1 78 FB 88 FD 86 58 A8 89 7B 22 8C D0 E8 71 FC Fax: 229 75 18 +-------------------------------------------------------------------------+ From gcc-return-8754-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 16:14:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4115 invoked by alias); 3 Aug 1999 16:14:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4098 invoked from network); 3 Aug 1999 16:14:23 -0000 Received: from link.csem.ch (138.131.145.25) by egcs.cygnus.com with SMTP; 3 Aug 1999 16:14:23 -0000 Received: from exchsrv.csem.ch by link.csem.ch; Tue, 3 Aug 1999 18:14:56 +0200 (MET DST) Received: from salsa (salsa.csem.ch [138.131.170.33]) by exchsrv.csem.ch with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QF0527XH; Tue, 3 Aug 1999 18:12:57 +0100 Message-Id: <4.1.19990803181036.02222a00@exchsrv> X-Sender: fmm@exchsrv X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 03 Aug 1999 18:13:33 +0200 To: gcc@gcc.gnu.org From: Fernando Mato Mira Subject: config.sub bug for Wind River Systems' VxWorks Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" for the -wrs case, it reads: os=vxworks instead of the correct os=-vxworks Fernando D. Mato Mira Real-Time SW Eng & Networking Advanced Systems Engineering Division CSEM Jaquet-Droz 1 email: matomira AT acm DOT org CH-2007 Neuchatel tel: +41 (32) 720-5157 Switzerland FAX: +41 (32) 720-5720 www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html From gcc-return-8755-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 16:35:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6916 invoked by alias); 3 Aug 1999 16:35:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6868 invoked from network); 3 Aug 1999 16:35:46 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 3 Aug 1999 16:35:46 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id JAA08072; Tue, 3 Aug 1999 09:35:14 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id JAA07922; Tue, 3 Aug 1999 09:35:09 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id JAA06896; Tue, 3 Aug 1999 09:35:09 -0700 Message-Id: <199908031635.JAA06896@atrus.synopsys.com> Subject: Re: Sourceware synchronisation. To: brendan@dgs.monash.edu.au Date: Tue, 3 Aug 99 9:35:08 PDT Cc: egcs@egcs.cygnus.com, binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com, newlib@sourceware.cygnus.com In-Reply-To: <37A650C1.30AFAC2A@dgs.monash.edu.au>; from "Brendan Simon" at Aug 3, 99 12:15 pm X-Mailer: ELM [version 2.3 PL11] Brendan Simon writes: > Now that the sourceware CD is available quarterly, I was wondering what > the chances are of synchronising new releases of sourceware projects > (binutils, gcc, newlib & gdb are the ones that mainly interest me. I'm > not sure what else is on the sourceware CD as I do not have one yet). While more cooperation is certainly possible on the common components (e.g. libiberty, configure-related stuff), the chances of synchronizing the schedules for the convenience of the quarterly Cygnus sourceware CDs is zero. GCC is not a "sourceware project" (that is, it is not controlled by Cygnus -- "sourceware" is a Cygnus term), and the steering committee has pledged to avoid conflicts of interest, e.g. scheduling releases for the convenience of one company. (I'm a member of the committee). We are grateful for all of Cygnus's contributions of resources, but we are already having problems with GCC/EGCS being perceived as a Cygnus-controlled project. It is not. It is a net-wide project. Of course, Cygnus is free to create internal releases that are more synchronized, or that provide features to paying customers before the general public gets them, this is fine. And Cygnus folks are free to help us keep things like libiberty in sync for easier integration down the road. But the official GCC has to remain neutral. Sorry. From gcc-return-8756-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 16:59:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12222 invoked by alias); 3 Aug 1999 16:58:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12166 invoked from network); 3 Aug 1999 16:58:31 -0000 Received: from mwunix.mitre.org (128.29.154.1) by egcs.cygnus.com with SMTP; 3 Aug 1999 16:58:31 -0000 Received: from pogo.mitre.org (pogo.mitre.org [128.29.83.22]) by mwunix.mitre.org (8.9.3/8.9.3) with ESMTP id MAA24330 for ; Tue, 3 Aug 1999 12:58:26 -0400 (EDT) Received: (from klouis@localhost) by pogo.mitre.org (8.8.8+Sun/8.8.8) id MAA27911; Tue, 3 Aug 1999 12:56:08 -0400 (EDT) Date: Tue, 3 Aug 1999 12:56:08 -0400 (EDT) Message-Id: <199908031656.MAA27911@pogo.mitre.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gcc@gcc.gnu.org Subject: GCC 2.95 Compilation X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Reply-To: klouis@mitre.org From: "Kurt F. Louis" I have successfully built and installed GCC 2.95 on an HP workstation running HP-UX 10.20. The output from /config.guess is as follows: hppa2.0-hp-hpux10.20 I am using the GNU assembler (gas) as recommended by specifying the "--with-gnu-as" option to the 'configure' script. Suggestion: it would be helpful to allow specification of a nonstandard directory in which to search for the GNU assembler (e.g., "--with-gnu-as=") so that those of us who are not system administrators could still install GCC for our own use in a nonstandard location. Instead, I simply modified the value of "MD_EXEC_PREFIX" in: /gcc/config/pa/pa-hpux10.h Kurt -- ----------------------------------------------------------------------------- Kurt F. Louis MS W518 Senior Simulation & Modeling Engineer Information Systems & Technology Div. Email: klouis@mitre.org The MITRE Corporation Voice: (703) 883-3324 (Reston/VMail) 1820 Dolley Madison Boulevard Voice: (703) 883-1227 (Westgate) McLean, VA 22102-3481 Fax : (703) 883-3343 ----------------------------------------------------------------------------- From gcc-return-8757-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 17:05:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14221 invoked by alias); 3 Aug 1999 17:04:58 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14173 invoked from network); 3 Aug 1999 17:04:52 -0000 Received: from caip.rutgers.edu (128.6.236.10) by egcs.cygnus.com with SMTP; 3 Aug 1999 17:04:52 -0000 Received: (from ghazi@localhost) by caip.rutgers.edu (8.9.3/8.9.3) id NAA25244; Tue, 3 Aug 1999 13:04:47 -0400 (EDT) Date: Tue, 3 Aug 1999 13:04:47 -0400 (EDT) From: "Kaveh R. Ghazi" Message-Id: <199908031704.NAA25244@caip.rutgers.edu> To: autogen@linuxbox.com, ddsinc09@ix.netcom.com, egcs@egcs.cygnus.com Subject: Re: New AutoGen > From: korbb@egcs.cygnus.com > > I have installed a new autogen-4.5.5 in: > > [...] > > If anyone has problems, please let me know so I can fix it > before making an announcement on FreshMeat. I hope to be > ready to do that before LinuxWorld. > > Regards, > Bruce Actually if portability is a concern, I had lots of trouble. 1. There are lots of uses of gcc extensions in the source, mainly "extern inline" and "static inline". 2. Building when srcdir != builddir was broken. Some headers couldn't be found. Some headers were rebuilt in the builddir. 3. After trying to update the source, it tried to rebuild some headers, but that crashed awk (on solaris2.7,) so I had to use gawk. (I don't think a gawk dependency is a great thing for portability.) 4. There appear to be some K&R violations, but I won't even get to these until I can build with an ANSI compiler != gcc. :-) If you would please fix the above problems 1-3 and get autogen to compile with at least one non-gcc compiler, I would greatly appreciate it. Thanks, --Kaveh -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions From gcc-return-8758-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 18:00:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22805 invoked by alias); 3 Aug 1999 18:00:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22780 invoked from network); 3 Aug 1999 18:00:31 -0000 Received: from legend.janet.ucla.edu (128.97.92.142) by egcs.cygnus.com with SMTP; 3 Aug 1999 18:00:31 -0000 Received: from localhost (tsiatsis@localhost) by legend.janet.ucla.edu (8.8.8/8.8.8) with SMTP id LAA22449 for ; Tue, 3 Aug 1999 11:00:30 -0700 (PDT) Date: Tue, 3 Aug 1999 11:00:29 -0700 (PDT) From: Vlasios Tsiatsis To: gcc@gcc.gnu.org Subject: Question about GCC Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I hava a laptop with Windows95 an it and no C language on it. I was thinking of building GCC on this machine but I don't know if there is a distribution of GCC for Windows or DOS . If there is where can I find it ? thank you very much, Vlasios Tsiatsis From gcc-return-8759-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 18:19:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26649 invoked by alias); 3 Aug 1999 18:19:12 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26575 invoked from network); 3 Aug 1999 18:19:02 -0000 Received: from unknown (HELO stargate.astr.lu.lv) (195.13.132.244) by egcs.cygnus.com with SMTP; 3 Aug 1999 18:19:02 -0000 Received: from hal (unverified [195.13.134.67]) by stargate.astr.lu.lv (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 03 Aug 1999 21:19:13 +0300 From: Andris Pavenis Organization: AI LU To: Vlasios Tsiatsis , gcc@gcc.gnu.org Subject: Re: Question about GCC Date: Tue, 3 Aug 1999 21:15:14 +0000 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain References: MIME-Version: 1.0 Message-Id: <99080321185400.00155@hal> Content-Transfer-Encoding: 8bit On Tue, 03 Aug 1999, Vlasios Tsiatsis wrote: > Hi, > > I hava a laptop with Windows95 an it and no C language on it. > I was thinking of building GCC on this machine but I don't know > if there is a distribution of GCC for Windows or DOS . For DOS You can look for DJGPP: http://www.delorie.com/djgpp/ Works Ok also under Win95. There is also related mailing list (and newsgroup comp.os.msdos.djgpp) Andris From gcc-return-8760-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 18:20:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27117 invoked by alias); 3 Aug 1999 18:20:19 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27060 invoked from network); 3 Aug 1999 18:20:14 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 3 Aug 1999 18:20:14 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id MAA06078; Tue, 3 Aug 1999 12:18:31 -0600 X-Mailer: exmh version 2.0.2 To: Marc Girod cc: gcc@gcc.gnu.org Subject: Re: gcc 2.95 on HP-UX 10.20: -g ? Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 03 Aug 1999 15:42:31 +0300. <199908031242.PAA21808@anvil.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Aug 1999 12:18:31 -0600 Message-ID: <6075.933704311@upchuck.cygnus.com> From: Jeffrey A Law In message <199908031242.PAA21808@anvil.ntc.nokia.com>you write: > This is what I had done with egcs 1.1.2. The version of as is from > binutils-2.9.1. > I configured and successfully built there with "make bootstrap", > without a "-g option disabled." warning. You need to configure gcc with the --with-gnu-as option so that gcc knows to expect the gnu assembler.jeff From gcc-return-8761-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 20:18:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13427 invoked by alias); 3 Aug 1999 20:18:00 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13304 invoked from network); 3 Aug 1999 20:17:32 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 3 Aug 1999 20:17:32 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id QAA22283 for ; Tue, 3 Aug 1999 16:17:21 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id QAA18897 for gcc@gcc.gnu.org; Tue, 3 Aug 1999 16:17:20 -0400 (EDT) Date: Tue, 3 Aug 1999 16:17:20 -0400 (EDT) From: John Wehle Message-Id: <199908032017.QAA18897@jwlab.FEITH.COM> To: gcc@gcc.gnu.org Subject: GC and static function optimizations Content-Type: text It looks like some work is underway to implement better memory management for gcc. Does this make it more feasible to postpone outputting static functions until the entire input file has been processed? This allows for certain optimizations which currently are not possible. For example: At one point I had a x86 patch that didn't bother emitting instructions to load the PIC register if the static function was only accessed by other functions within the same file. At the time it was rejected due to concerns about possible excessive memory consumption caused by having to remember the static functions until the end of the input file. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-8762-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 20:42:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18096 invoked by alias); 3 Aug 1999 20:42:02 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18043 invoked from network); 3 Aug 1999 20:41:35 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 3 Aug 1999 20:41:35 -0000 Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id QAA02362; Tue, 3 Aug 1999 16:41:16 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com by world.std.com (TheWorld/Spike-2.0) id AA11201; Tue, 3 Aug 1999 16:38:47 -0400 Received: (qmail 9573 invoked by uid 500); 3 Aug 1999 20:36:50 -0000 Date: 3 Aug 1999 20:36:50 -0000 Message-Id: <19990803203650.9572.qmail@deer> To: egcs@tantalophile.demon.co.uk Cc: law@cygnus.com, ak@muc.de, jquinn@nortelnetworks.com, egcs@egcs.cygnus.com Cc: craig@jcb-sc.com In-Reply-To: <19990803103258.C29844@pcep-jamie.cern.ch> (message from Jamie Lokier on Tue, 3 Aug 1999 10:32:58 +0200) Subject: Re: Simple RTL question (was: New cfg code) References: <3770.933655956@upchuck.cygnus.com> <19990803103258.C29844@pcep-jamie.cern.ch> >Jeffrey A Law wrote: >> In message you write: >> > Would it be possible to generate those parts of rtl.texi mechanically >> > from rtl.def (via a perl script or similar) ? >> It would be possible. >> >> However, in my experience, this does not actually work all that well. Just >> look at BFD which uses this kind of scheme. > >Agree 100% on BFD. > >My (entirely theoretical ;-) approach to this sort of thing is to >maintain docs and code together, and instead of mechanically generating >the entire docs, _verify_ the docs instead. So if the docs are missing >a field or function, the verifier script warns. Maybe it even inserts >the missing function with "not yet documented". Sometimes a good doc >string can be found with the thing to be documented, but sometimes it's >good to write something separately, that better fits a manual. I haven't looked at BFD. Others interested in what's possible, in terms of architecting things like this, might want to look at g77's documentation vis-a-vis its tables of intrinsics. In short, there are certain kinds of integration of docs and code, or, more precisely, deriving docs from code (or docs *and* code from a common, code-like source) that I think are very much worth doing. It's knowing where and how to draw the line between what is worth doing and what is best left to by-hand work that I feel takes some careful thought. I think I did a pretty good job in that sense in g77's case, and, indeed, made use of a way to spot missing doc entries for intrinsics (forget what it was offhand ;-) to work on filling out the docs over time. Not quite sure whether RTL is a great candidate for this sort of thing, however. Haven't thought about it much. tq vm, (burley) From gcc-return-8763-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 20:50:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19938 invoked by alias); 3 Aug 1999 20:50:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19847 invoked from network); 3 Aug 1999 20:50:25 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 3 Aug 1999 20:50:25 -0000 Received: from rtl.cygnus.com (rtl.cygnus.com [205.180.230.21]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA22519; Tue, 3 Aug 1999 13:50:15 -0700 (PDT) From: Jim Wilson Received: (wilson@localhost) by rtl.cygnus.com (8.6.12/8.6.4) id NAA26232; Tue, 3 Aug 1999 13:50:14 -0700 Date: Tue, 3 Aug 1999 13:50:14 -0700 Message-Id: <199908032050.NAA26232@rtl.cygnus.com> To: joel@OARcorp.com Subject: Re: gcc 2.95 i960 question Newsgroups: cygnus.egcs In-Reply-To: Organization: Cygnus Solutions, CA Cc: egcs@sourceware.cygnus.com In article you write: >Is this something not setup right in the i960-rtems target or is this just >an embedded multilib option that has been turned on before its time? Yes, it is a little bit of sloppiness in the patches that were applied. First the option and a multilib was added. Then the option was disabled, but the multilib was not disabled at the same time. So we are building a multilib that can't be used, which is annoying but harmless. Jim From gcc-return-8764-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 21:05:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23584 invoked by alias); 3 Aug 1999 21:05:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23564 invoked from network); 3 Aug 1999 21:05:08 -0000 Received: from mongoose.slip.net (207.171.193.14) by egcs.cygnus.com with SMTP; 3 Aug 1999 21:05:08 -0000 Received: from slip-3 ([207.171.193.17] helo=slip-3.slip.net) by mongoose.slip.net with smtp (Exim 2.12 #4) id 11BlkA-0006W0-00 for gcc@gcc.gnu.org; Tue, 3 Aug 1999 14:05:06 -0700 Date: Tue, 3 Aug 1999 14:05:04 -0700 (PDT) From: Ben Rockwood To: gcc@gcc.gnu.org Subject: Can't compile: crt.o doesn't exsist? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Help!?! I've installed several diffrent distrobutions of Linux and had this problem on several diffrent ones... right out of the box! (well, ftp install) I try to compile something like imlib, gtk+, glib (not glibc) or fnlib and the configure script tells me that gcc can't compile executable and then spits this out into the config.log: configure:1022: checking for gcc configure:1135: checking whether the C compiler (gcc ) works configure:1151: gcc -o conftest conftest.c 1>&5 ld: cannot open crt1.o: No such file or directory configure: failed program was: #line 1146 "configure" #include "confdefs.h" main(){return(0);} [root@pris glib-1.2.3]# What's going on, or what am I doing wrong?! Thank you VERY much for any help!!!! benr. From gcc-return-8765-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 22:12:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1217 invoked by alias); 3 Aug 1999 22:12:31 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1166 invoked from network); 3 Aug 1999 22:12:25 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 3 Aug 1999 22:12:25 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id AAA15729; Wed, 4 Aug 1999 00:10:04 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id AAA01355; Wed, 4 Aug 1999 00:06:11 +0200 Date: Wed, 4 Aug 1999 00:06:11 +0200 Message-Id: <199908032206.AAA01355@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: lfarkas@mindmaker.hu CC: gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org In-reply-to: <37A6BA83.8EF1F0FF@mindmaker.hu> (message from Levente Farkas on Tue, 03 Aug 1999 11:46:43 +0200) Subject: Re: inner class in template class References: <37A6BA83.8EF1F0FF@mindmaker.hu> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > is it a correct code or just the compilers can understand me ?: Thanks for your bug report. At least, I suppose this is a bug report; if it is a question on C++, please ask that again in comp.lang.c++. g++ currently cannot compile your code, as the iostreams library is not conforming to the standard, yet. In particular, no templates named basic_ostream or char_traits are defined, which causes the errors you probably see. Hope this helps, Martin From gcc-return-8766-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 22:58:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6919 invoked by alias); 3 Aug 1999 22:58:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6815 invoked from network); 3 Aug 1999 22:58:03 -0000 Received: from milkyway.sirius-cafe.de (root@195.185.94.226) by egcs.cygnus.com with SMTP; 3 Aug 1999 22:58:03 -0000 Received: from knobisoft.de (isdn67.sirius-cafe.de [195.185.94.67]) by milkyway.sirius-cafe.de (8.8.5/8.8.5) with ESMTP id XAA27000; Tue, 3 Aug 1999 23:45:09 +0200 Message-ID: <37A77212.DEA30D4A@knobisoft.de> Date: Wed, 04 Aug 1999 00:49:54 +0200 From: Martin Knoblauch Reply-To: knobi@knobisoft.de Organization: Knobisoft :-), Freising X-Mailer: Mozilla 4.6 [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Problems running "gmake check" on IRIX-6.5 and True64 Unix 4.0E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, on two different platforms, I see problems during the "gmake check" phase of building gcc-2.95. In both cases, the "tool config file for unix" seems to be missing. Here is the relevant stuff from mips-sgi-irix6.3: % gmake check rootme=`pwd`; export rootme; \ srcdir=`cd ../../gcc-2.95/gcc; pwd` ; export srcdir ; \ cd testsuite; \ EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo ${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \ if [ -f ${rootme}/../expect/expect ] ; then \ TCL_LIBRARY=`cd .. ; cd ../../gcc-2.95/gcc/../tcl/library ; pwd` ; \ export TCL_LIBRARY ; fi ; \ `if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo ${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gcc WARNING: Couldn't find the global config file. WARNING: Couldn't find tool init file Test Run By knobi on Wed Aug 4 00:41:57 1999 Native configuration is mips-sgi-irix6.5 === gcc tests === Schedule of variations: unix Running target unix Using /usr/egcsroot/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/egcsroot/share/dejagnu/config/unix.exp as generic interface file for target. ERROR: Couldn't find tool config file for unix. === gcc Summary === Any ideas? It used to work for 2.93.xx snapshots. Thanks Martin -- +-----------------------------------------------------+ |Martin Knoblauch | |-----------------------------------------------------| |http://www.knobisoft.de |e-mail: | |-----------------------------------------------------| |fax2mail: +49-89-66617-52204 | +-----------------------------------------------------+ From gcc-return-8767-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 03 23:07:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9290 invoked by alias); 3 Aug 1999 23:07:41 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9200 invoked from network); 3 Aug 1999 23:07:18 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 3 Aug 1999 23:07:18 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id RAA07136; Tue, 3 Aug 1999 17:04:42 -0600 X-Mailer: exmh version 2.0.2 To: knobi@knobisoft.de cc: gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: Problems running "gmake check" on IRIX-6.5 and True64 Unix 4.0E Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 04 Aug 1999 00:49:54 +0200. <37A77212.DEA30D4A@knobisoft.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Aug 1999 17:04:42 -0600 Message-ID: <7133.933721482@upchuck.cygnus.com> From: Jeffrey A Law In message <37A77212.DEA30D4A@knobisoft.de>you write: > Hi, > > on two different platforms, I see problems during the "gmake check" > phase of building gcc-2.95. In both cases, the "tool config file for > unix" seems to be missing. Here is the relevant stuff from Please read the FAQ. jeff From gcc-return-8768-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 00:03:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15806 invoked by alias); 4 Aug 1999 00:03:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15782 invoked from network); 4 Aug 1999 00:03:30 -0000 Received: from paris.ics.uci.edu (mmdf@128.195.1.50) by egcs.cygnus.com with SMTP; 4 Aug 1999 00:03:30 -0000 Received: from star.ics.uci.edu by paris.ics.uci.edu id aa07898; 3 Aug 99 16:57 PDT Date: Tue, 3 Aug 1999 16:57:50 -0700 (PDT) From: Radu Cornea To: gcc@gcc.gnu.org Subject: GCC questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! I am currently working at a project that uses gcc. Therefore, I am trying to understand how the rtx statements and trees are handled and how the code is generated. I have the following questions: 1. Is there a function to convert a tree representation to the equivalent rtx? 2. What functions are available for debugging (like printing the tree or rtx)? 3. How can a code portion (a tree) be duplicated (this includes the creation of rtx and code generation)? 4. How can the last tree created be accessed? 5. I am asking these questions because I need to solve this problem in gcc: in some cases, gcc transforms initial structured code into unstructured code. This happens for example for if statements that have as condition logical OR (||) or AND (&&) expressions. In order to generate structured code, the then-statement have to be duplicated (as many times as the number of ORs or ANDs). For this, i need to save somehow the then-statement tree when it is generated and duplicate it (and of course, the jumps need to be changed). If anyone can help me on this I would be very grateful. Thanks, Radu Cornea. From gcc-return-8769-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 00:35:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22104 invoked by alias); 4 Aug 1999 00:35:04 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22082 invoked from network); 4 Aug 1999 00:35:00 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 4 Aug 1999 00:35:00 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id RAA22648; Tue, 3 Aug 1999 17:34:53 -0700 (PDT) Received: by kankakee.wrs.com (SMI-8.6/SMI-SVR4) id RAA23418; Tue, 3 Aug 1999 17:34:53 -0700 Date: Tue, 3 Aug 1999 17:34:53 -0700 From: mrs@wrs.com (Mike Stump) Message-Id: <199908040034.RAA23418@kankakee.wrs.com> To: gcc@gcc.gnu.org, radu@ics.uci.edu Subject: Re: GCC questions > Date: Tue, 3 Aug 1999 16:57:50 -0700 (PDT) > From: Radu Cornea > 1. Is there a function to convert a tree representation to the equivalent > rtx? Yes, see expand_expr. > 2. What functions are available for debugging (like printing the tree or > rtx)? Yes, see *debug* and print-*.c and .gdbinit > 3. How can a code portion (a tree) be duplicated (this includes the > creation of rtx and code generation)? This question is way to vague for me to answer. I know of dozens of ways to duplicate things... For example, one of my favorite ones is unsave_expr, but this is just one type of duplication. > 4. How can the last tree created be accessed? ? This isn't what you want to do. Or put another way, if you want to do this, you don't have the right integration philosophy. > 5. I am asking these questions because I need to solve this problem in gcc: > in some cases, gcc transforms initial structured code into unstructured > code. This happens for example for if statements that have as condition > logical OR (||) or AND (&&) expressions. In order to generate structured > code, the then-statement have to be duplicated (as many times as the number > of ORs or ANDs). For this, i need to save somehow the then-statement tree > when it is generated and duplicate it (and of course, the jumps need to be > changed). Ok, too bad you didn't say exactly what you wanted to do. Sounds like it is mostly outside the scope of compilation though. We can give better answers to your question, if the question is the right question. Tell us what you really want to do... I think what you want is an full function ast, that preserves constructs like if and while. If that is it, then if you can use just C++, then you might consider turning on the template code everywhere, and munching on it instead. In that style of code we preserve things like: DEFTREECODE (DECL_STMT, "decl_stmt", 'e', 3) DEFTREECODE (IF_STMT, "if_stmt", 'e', 3) DEFTREECODE (FOR_STMT, "for_stmt", 'e', 4) DEFTREECODE (WHILE_STMT, "while_stmt", 'e', 2) DEFTREECODE (DO_STMT, "do_stmt", 'e', 2) DEFTREECODE (RETURN_STMT, "return_stmt", 'e', 1) DEFTREECODE (BREAK_STMT, "break_stmt", 'e', 0) DEFTREECODE (CONTINUE_STMT, "continue_stmt", 'e', 0) DEFTREECODE (SWITCH_STMT, "switch_stmt", 'e', 2) DEFTREECODE (GOTO_STMT, "goto_stmt", 'e', 1) directly, and you can the walk that code and do what you want. But since I don't know what you want to do, I don't know if this is a solution to what you want to do. From gcc-return-8770-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 00:45:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23573 invoked by alias); 4 Aug 1999 00:45:02 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23520 invoked from network); 4 Aug 1999 00:44:29 -0000 Received: from smtp6.array3.laserlink.net (HELO smtp6.quixnet.net) (63.65.122.176) by egcs.cygnus.com with SMTP; 4 Aug 1999 00:44:29 -0000 Received: from diamond (1Cust218.tnt2.everett2.wa.da.uu.net [153.35.254.218]) by smtp6.quixnet.net (8.9.3/8.9.3) with SMTP id UAA03882 for ; Tue, 3 Aug 1999 20:44:06 -0400 (EDT) Message-ID: <000101bede16$fa93f580$dafe2399@diamond> Reply-To: "Ryan and Kari's Email" From: "Ryan and Kari's Email" To: Subject: trouble downloading Date: Tue, 3 Aug 1999 18:16:26 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Trying to download GCC 2.95 from web site, no response. Problem with server? Please advise. Thanks, Kg From gcc-return-8771-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 00:57:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25905 invoked by alias); 4 Aug 1999 00:57:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25875 invoked from network); 4 Aug 1999 00:57:44 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 4 Aug 1999 00:57:44 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id SAA07624; Tue, 3 Aug 1999 18:55:55 -0600 X-Mailer: exmh version 2.0.2 To: "Ryan and Kari's Email" cc: gcc@gcc.gnu.org Subject: Re: trouble downloading Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 03 Aug 1999 18:16:26 PDT. <000101bede16$fa93f580$dafe2399@diamond> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Aug 1999 18:55:55 -0600 Message-ID: <7621.933728155@upchuck.cygnus.com> From: Jeffrey A Law In message <000101bede16$fa93f580$dafe2399@diamond>you write: > Trying to download GCC 2.95 from web site, no response. Problem with > server? Please advise. Thanks, Kg >From precisely which site? I just tried from egcs.cygnus.com and go.cygnus.com and it worked without any problems. jeff From gcc-return-8772-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 01:54:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1962 invoked by alias); 4 Aug 1999 01:54:09 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1930 invoked from network); 4 Aug 1999 01:54:01 -0000 Received: from host162.nashville.com (HELO rjlhome.sco.com) (207.65.231.162) by egcs.cygnus.com with SMTP; 4 Aug 1999 01:54:01 -0000 Received: (from robertl@localhost) by rjlhome.sco.com (8.8.8/SCO5) id UAA01327; Tue, 3 Aug 1999 20:53:19 -0500 (CDT) Date: Tue, 3 Aug 1999 20:53:19 -0500 From: Robert Lipe To: Rob Kramer Cc: egcs@egcs.cygnus.com Subject: Re: Hmm. GCC 2.95 build fails on i586-pc-sco3.2v5.0.2 Message-ID: <19990803205319.Z8146@rjlhome.sco.com> References: <199908030720.PAA11899@eastgate.cyberway.com.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95us In-Reply-To: <199908030720.PAA11899@eastgate.cyberway.com.sg>; from Rob Kramer on Tue, Aug 03, 1999 at 03:18:51PM +0800 > " If you choose to configure with --enable-shared you should also > specificy --with-gnu-as --disable-multilib even if you are not using > the GNU assembler. In doing so you will give up the ability to > generate COFF executables as described below. This combination of > flags is necessary to suppress negative interactions with multilibing." > > '..even if you are not using the GNU assembler'? Oh. That. Those instructions are somewhere between misleading and just plain wrong. The problem is that --with-gnu-as turns off the code in GCC that tells the native assembler how to flip between the two supported object formats. So now GCC defaults to ELF but the native assembler defaults to COFF and bad things happen. We either need to make disable-multilib not disable the part of GCC that makes it assert the "generate ELF" flag or we just need to doc that for --enable-shared that requires the GNU assembler. Kean has a pending patch that might be a better solution. He now allows you to invoke a completely different assembler depending upon the compiler flags. That's another ticket out of here. For about six Really Good Beers I'd just go nuts and pull this multilibbing crap out of OpenServer completely. If Kean and I knew in '95 what we know now, we would have killed the COFF beast then and been free of multilib hell... > While compiling, I got the following error, but after restarting make all > seemed fine. > xgcc: Internal compiler error: program as got fatal signal 11 I did a lot of builds on a slightly broken SMP system for many months. The symptom of failure was almost always "random" signal 11's in as when building EGCS... RJL From gcc-return-8773-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 07:11:40 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7625 invoked by alias); 4 Aug 1999 07:11:37 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7450 invoked from network); 4 Aug 1999 07:10:06 -0000 Received: from smtp.comptel.com (192.102.20.151) by egcs.cygnus.com with SMTP; 4 Aug 1999 07:10:06 -0000 Received: from miina.comptel.com (unverified [194.240.21.9]) by smtp.comptel.com (Data Fellows SMTPRS 2.04) with ESMTP id ; Wed, 04 Aug 1999 10:04:00 +0300 Received: from ctws1443 (xf006.comptel.com [195.237.135.6]) by miina.comptel.com with SMTP (8.8.6 (PHNE_14041)/8.7.1) id KAA05998 for ; Wed, 4 Aug 1999 10:08:44 +0300 (EETDST) From: "Jussi Lassila" To: Subject: GCC 2.95 Build succesful on hppa2.0-hp-hpux10.20 Date: Wed, 4 Aug 1999 10:09:43 +0300 Message-Id: <001001bede48$539248e0$0687edc3@comptel.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi I built GCC 2.95 on hppa2.0-hp-hpux10.20 succesfully. It compiled on native 'as' assembler (could not use -g option though), and also on GAS (-g worked fine). For some reason though, when I used the --with-gnu-as option, it did not find/use the gnu assembler I had in my path, but instead it used the native one, and failed to compile. When I included the --with-as=/path_to_gnu_as it worked fine. Jussi From gcc-return-8774-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 07:22:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9418 invoked by alias); 4 Aug 1999 07:22:21 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9359 invoked from network); 4 Aug 1999 07:20:58 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 4 Aug 1999 07:20:58 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id BAA08958; Wed, 4 Aug 1999 01:19:15 -0600 X-Mailer: exmh version 2.0.2 To: John Wehle cc: egcs@egcs.cygnus.com Subject: Re: try_split lossage Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 16 Jun 1999 13:51:35 EDT. <199906161751.NAA13265@jwlab.FEITH.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Aug 1999 01:19:15 -0600 Message-ID: <8955.933751155@upchuck.cygnus.com> From: Jeffrey A Law In message <199906161751.NAA13265@jwlab.FEITH.COM>you write: > An insn may have various characteristics (such as CONST_CALL_P, > INSN_ANNULLED_BRANCH_P, INSN_FROM_TARGET_P, RTX_FRAME_RELATED_P) > which affect code generation. try_split attempts to replace the > insn with other insn(s). What isn't clear to me is how the new > insn(s) inherit the characteristics of the insn which is being > replaced. > > Should try_split either abort or avoid splitting insns which > have any of these characteristics? Well, losing a CONST_CALL_P or RTX_FRAME_RELATED_P shouldn't cause any serious problems. However, losing the ANNULLED_BRANCH_P or INSN_FROM_TARGET_P could cause problems. But we shouldn't get insns with those bits set because they would have already been split by the delay slot scheduler. jeff From gcc-return-8775-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 07:23:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10012 invoked by alias); 4 Aug 1999 07:23:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9392 invoked from network); 4 Aug 1999 07:22:05 -0000 Received: from ns1116.munich.netsurf.de (HELO fred.muc.de) (none@195.180.235.116) by egcs.cygnus.com with SMTP; 4 Aug 1999 07:22:05 -0000 Received: from andi by fred.muc.de with local (Exim 2.05 #1) id 11BvO3-0000Ih-00; Wed, 4 Aug 1999 09:22:55 +0200 To: law@cygnus.com cc: egcs@egcs.cygnus.com Subject: Re: PATCH for loop.c, SIGFPE with bad integer operands on host (linux-)ix86 References: <7368.933725371@upchuck.cygnus.com> From: Andi Kleen Date: 04 Aug 1999 09:22:54 +0200 In-Reply-To: law@cygnus.com's message of "4 Aug 1999 02:12:12 +0200" Message-ID: Lines: 29 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii law@cygnus.com (Jeffrey A Law) writes: > In message you write: > > There's a (well-known?) problem with integer arithmetic on > > (linux-)ix86 platforms: Doing signed integer modulus or > > division on (0x80000000 / -1) or (0x80000000 % -1) gives a > > SIGFPE. This is ix86-specific, and maybe possible to work > > around in the right interrupt handler in the kernel for > > those who know that stuff. This happens on linux 2.0.30 > > with a PPro as well as on linux 2.2.1 with a PII, and > > probably on non-linux systems as well; I believe cygwin b20.1 > > has the same problem. > The kernel trap handlers need to be fixed. > > It's a common problem, in fact, I had to fix PA kernels in a similar manner > a couple times over the years. x86 has no magic traphandlers for math in kernel, it is all done in microcode. The kernel just hands on the exception as SIGFPE without even looking at it. Adding disassembly hacks to the kernel is probably not worth it (if you seriously want you can add it in user space, but it is probably better to fix the code), also the x86 behaviour is allowed by the C standard. Unfortunately the CPU has no easy way to mask it. -Andi -- This is like TV. I don't like TV. From gcc-return-8776-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 07:49:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14103 invoked by alias); 4 Aug 1999 07:49:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14088 invoked from network); 4 Aug 1999 07:49:13 -0000 Received: from s2.smtp.oleane.net (195.25.12.6) by egcs.cygnus.com with SMTP; 4 Aug 1999 07:49:13 -0000 Received: from iis000.microdata.fr (mailhost.microprocess.com [62.161.233.21]) by s2.smtp.oleane.net with ESMTP id JAA59984 for ; Wed, 4 Aug 1999 09:49:05 +0200 (CEST) Received: by IIS000.microdata.fr with Internet Mail Service (5.5.1960.3) id <3QF3V25Z>; Wed, 4 Aug 1999 09:49:05 +0200 Message-ID: <3AC9A1611DF4D211AA8E00105AA56D8A048A8F@IIS000.microdata.fr> From: Patrick Lerda To: "'gcc@gcc.gnu.org'" Subject: PowerPC gcc 2.8.1 generate wrong code while compiling linux 2.2.9 Date: Wed, 4 Aug 1999 09:48:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BEDE4D.B63218C0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BEDE4D.B63218C0 Content-Type: text/plain I found the problem while compiling linux 2.2.9 on PowerPC. The file fs/ext2/balloc.c: gdp->bg_free_blocks_count = cpu_to_le16(le16_to_cpu(gdp->bg_free_blocks_count) - 1); Is miscompiled whith gcc 2.8.1, and I always get: gdp>bg_free_blocks_count=-1. I tried the compiler used by RedHat for PowerPC (a prereleased of egcs 1.0.2), and this new compiler give the right result. Linux use some asm functions in cpu_to_le16 and le16_to_cpu, these functions combinated seem to give a bad result. If you know the most reliable version of gcc to compile linux on PowerPC, and how to make a cross compiler of GCC-2.9.5 for powerpc on an intel box let me know. Thanks LERDA Patrick ------ =_NextPart_001_01BEDE4D.B63218C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable PowerPC gcc 2.8.1 generate wrong code while compiling linux = 2.2.9

I found the problem while compiling = linux 2.2.9 on PowerPC. The file fs/ext2/balloc.c:

        gdp->bg_free_blocks_count =3D = cpu_to_le16(le16_to_cpu(gdp->bg_free_blocks_count) - 1);

Is miscompiled whith gcc 2.8.1, and I = always get: gdp>bg_free_blocks_count=3D-1.
I tried the compiler used by RedHat = for PowerPC (a prereleased of egcs 1.0.2), and this new
compiler give the right result. Linux = use some asm functions in cpu_to_le16 and le16_to_cpu,
these functions combinated seem to = give a bad result.

If you know the most reliable version = of gcc to compile linux on PowerPC, and how to make
a cross compiler of GCC-2.9.5 for = powerpc on an intel box let me know.

Thanks


LERDA Patrick

------ =_NextPart_001_01BEDE4D.B63218C0-- From gcc-return-8777-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 07:49:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14333 invoked by alias); 4 Aug 1999 07:49:31 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14296 invoked from network); 4 Aug 1999 07:49:28 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 4 Aug 1999 07:49:28 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id DAA00271; Wed, 4 Aug 1999 03:49:25 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id DAA19869; Wed, 4 Aug 1999 03:49:23 -0400 (EDT) Date: Wed, 4 Aug 1999 03:49:23 -0400 (EDT) From: John Wehle Message-Id: <199908040749.DAA19869@jwlab.FEITH.COM> To: law@cygnus.com cc: egcs@egcs.cygnus.com Subject: Re: try_split lossage Content-Type: text > In message <199906161751.NAA13265@jwlab.FEITH.COM>you write: > > An insn may have various characteristics (such as CONST_CALL_P, > > INSN_ANNULLED_BRANCH_P, INSN_FROM_TARGET_P, RTX_FRAME_RELATED_P) > > which affect code generation. try_split attempts to replace the > > insn with other insn(s). What isn't clear to me is how the new > > insn(s) inherit the characteristics of the insn which is being > > replaced. > > > > Should try_split either abort or avoid splitting insns which > > have any of these characteristics? > Well, losing a CONST_CALL_P or RTX_FRAME_RELATED_P shouldn't cause any serious > problems. The following is from dwarf2out_frame_debug: if (! RTX_FRAME_RELATED_P (insn)) { dwarf2out_stack_adjust (insn); return; } dwarf2out_stack_adjust has the comment: /* Check INSN to see if it looks like a push or a stack adjustment, and make a note of it if it does. EH uses this information to find out how much extra space it needs to pop off the stack. */ There seems to be the potential to break EH if RTX_FRAME_RELATED_P is incorrect, however I'm somewhat naive when it comes to EH or dwarf2. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-8778-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 08:11:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18859 invoked by alias); 4 Aug 1999 08:11:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18844 invoked from network); 4 Aug 1999 08:11:04 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 4 Aug 1999 08:11:04 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id CAA09353; Wed, 4 Aug 1999 02:09:25 -0600 X-Mailer: exmh version 2.0.2 To: Fernando Mato Mira cc: gcc@gcc.gnu.org Subject: Re: config.sub bug for Wind River Systems' VxWorks Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 03 Aug 1999 18:13:33 +0200. <4.1.19990803181036.02222a00@exchsrv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Aug 1999 02:09:25 -0600 Message-ID: <9350.933754165@upchuck.cygnus.com> From: Jeffrey A Law In message <4.1.19990803181036.02222a00@exchsrv>you write: > for the -wrs case, it reads: > > os=vxworks > > instead of the correct > > os=-vxworks Thanks. This has been fixed for gcc-2.95.1. jeff From gcc-return-8779-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 08:19:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20154 invoked by alias); 4 Aug 1999 08:19:05 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20127 invoked from network); 4 Aug 1999 08:18:58 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 4 Aug 1999 08:18:58 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id CAA09400; Wed, 4 Aug 1999 02:17:18 -0600 X-Mailer: exmh version 2.0.2 To: Richard Henderson cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: New cfg code Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 03 Aug 1999 02:30:59 PDT. <19990803023059.A27430@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Aug 1999 02:17:18 -0600 Message-ID: <9397.933754638@upchuck.cygnus.com> From: Jeffrey A Law In message <19990803023059.A27430@cygnus.com>you write: > Nr 2 is my preferred short-term solution. That's the direction I was leaning. > Long term, of course, > we've got to get rid of ADDR_VEC as an instruction completely. > Probably by hanging a SEQUENCE containing the interesting label > and ADDR_VEC off of a reg note on the tablejump insn. Yup. > Nr 1 pollutes CSE with stuff it shouldn't be having to think about. Yup. And it's not any uglier to do it in jump. > Nr 3 results in uglier CFGs. Yes. > Attached is a patch that allows the test to succeed. It's not as > friendly as it might be, as optimization phase sequencing leaves > the (code_label 80) around much longer than I would have liked. > It is gone before final though, so it's not the end of the world. Another approach I didn't mention was to run delete_trivially_dead_insns after cse2. That allows us to kill the final outstanding reference to the label which in turn allowed flow to delete the label. But I didn't particularly like that approach :-) > * jump.c (delete_insn): Delete the addr_vec when deleting a tablejump. I went ahead and installed this. Thanks, jeff From gcc-return-8780-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 08:29:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22575 invoked by alias); 4 Aug 1999 08:29:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22560 invoked from network); 4 Aug 1999 08:29:28 -0000 Received: from dialup092.albatross.co.nz (HELO loki.albatross.co.nz) (nobody@203.97.5.92) by egcs.cygnus.com with SMTP; 4 Aug 1999 08:29:28 -0000 Received: from localhost (psycho@localhost) by loki.albatross.co.nz (8.9.3/8.9.3) with ESMTP id UAA19042 for ; Wed, 4 Aug 1999 20:30:39 +1200 X-Authentication-Warning: loki.albatross.co.nz: psycho owned process doing -bs Date: Wed, 4 Aug 1999 20:30:39 +1200 (NZST) From: Keith Duthie To: gcc@gcc.gnu.org Subject: specs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I'd like to suggest not using specs if it's a directory. For example, xfree86 has a directory called specs which causes egcs/gcc-2.95 to exit with an error message. -- Understanding is a three edged sword. Do you *want* to get the point? http://www.albatross.co.nz/~psycho/ O- From gcc-return-8781-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 09:20:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27796 invoked by alias); 4 Aug 1999 09:20:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27768 invoked from network); 4 Aug 1999 09:20:24 -0000 Received: from nexusel.demon.co.uk (HELO globe.nexus.co.uk) (158.152.30.195) by egcs.cygnus.com with SMTP; 4 Aug 1999 09:20:24 -0000 Received: from [192.0.0.21] (helo=fountain.nexus.co.uk ident=mail) by globe.nexus.co.uk with smtp (Exim 2.12 #1) id 11BxB5-0000LV-00; Wed, 4 Aug 1999 10:17:39 +0100 Received: from [::ffff:127.0.0.1] (helo=fountain.nexus.co.uk ident=pb) by fountain.nexus.co.uk with esmtp (Exim 2.12 #4) id 11BxB5-0003s2-00; Wed, 4 Aug 1999 10:17:39 +0100 X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: Keith Duthie cc: gcc@gcc.gnu.org Subject: Re: specs In-reply-to: Your message of "Wed, 04 Aug 1999 20:30:39 +1200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Aug 1999 10:17:39 +0100 From: Philip Blundell Message-Id: In message , Kei th Duthie writes: >Hi, I'd like to suggest not using specs if it's a directory. For example, >xfree86 has a directory called specs which causes egcs/gcc-2.95 to exit >with an error message. If gcc is trying to pick up specs from your current directory, chances are this is because you have some environment variable telling it to do so. Even if you tell it not to use directories you will lose if you happen to have a *file* called `specs'. I've never been especially convinced that following LIBRARY_PATH (or whatever it is) to find the specs is desirable, in fact. p. From gcc-return-8782-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 09:35:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29548 invoked by alias); 4 Aug 1999 09:35:49 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29518 invoked from network); 4 Aug 1999 09:35:31 -0000 Received: from unknown (HELO trantor.dso.org.sg) (192.190.204.1) by egcs.cygnus.com with SMTP; 4 Aug 1999 09:35:31 -0000 Received: from demerzel.dso.org.sg (demerzel.dso.org.sg [192.190.204.8]) by trantor.dso.org.sg (8.9.3/8.9.3) with ESMTP id RAA26252 for ; Wed, 4 Aug 1999 17:37:32 +0800 (SGT) Received: from dso.org.sg by demerzel.dso.org.sg (8.9.3/8.8.5) with ESMTP id RAA01344 for ; Wed, 4 Aug 1999 17:35:18 +0800 (SGT) Message-ID: <37A80995.DFE0361@dso.org.sg> Date: Wed, 04 Aug 1999 17:36:22 +0800 From: Richard Shih-Ping Chan Organization: DSO National Laboratories X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Solaris 64-bit support is in 2.95! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For those of you looking for Solaris 64-bit support the target is there in gcc 2.95 as sparcv9-sun-solaris2.7. As we know some people have raised the incompleteness of this target so YMMV. Also to get it to work you may have to build it as a cross compiler first. I.e., use a sparc 32 compiler to build a sparc32 to sparc64 cross, then build a native compiler. From gcc-return-8783-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 10:50:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6899 invoked by alias); 4 Aug 1999 10:50:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6884 invoked from network); 4 Aug 1999 10:50:33 -0000 Received: from mail2.gmx.net (qmailr@194.221.183.62) by egcs.cygnus.com with SMTP; 4 Aug 1999 10:50:33 -0000 Received: (qmail 29841 invoked by uid 0); 4 Aug 1999 10:50:30 -0000 Received: from ph-ascend-ppp28.ph-weingarten.de (HELO PowerBox.MysticWorld.de) (141.69.150.238) by mail2.gmx.net with SMTP; 4 Aug 1999 10:50:30 -0000 Received: from localhost (localhost [[UNIX: localhost]]) by PowerBox.MysticWorld.de (8.9.3/8.9.3) id MAA06089 for gcc@gcc.gnu.org; Wed, 4 Aug 1999 12:53:23 +0200 From: Alexander Feigl To: gcc@gcc.gnu.org Subject: Any successful builds of QT 1.44 with gcc 2.95 / glibc 2.1.1 on i386? Date: Wed, 4 Aug 1999 12:49:53 +0200 X-Mailer: KMail [version 1.0.26] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99080412532300.05837@PowerBox.MysticWorld.de> Content-Transfer-Encoding: 8bit Hello! Is there anybody who was successful to build QT 1.44 with gcc 2.95 for glibc 2.1.1 on i386 linux. QT 1.44 makes trobule on my system (internal compiler error) and it would be very useful if I know whether this is a general problem or a problem caused by my system configuration. Greetings Alexander Feigl From gcc-return-8784-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 12:01:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16056 invoked by alias); 4 Aug 1999 12:01:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16010 invoked from network); 4 Aug 1999 12:01:32 -0000 Received: from mailgw.chips.ibm.com (192.91.197.8) by egcs.cygnus.com with SMTP; 4 Aug 1999 12:01:32 -0000 Received: from mailrelay.btv.ibm.com (mailrelay.btv.ibm.com [9.66.15.39]) by mailgw.chips.ibm.com (8.8.8/8.8.8) with ESMTP id IAA11202 for ; Wed, 4 Aug 1999 08:01:30 -0400 Received: from apache4.btv.ibm.com (apache4.btv.ibm.com [9.66.143.20]) by mailrelay.btv.ibm.com (8.8.8/8.8.8) with ESMTP id IAA29862 for ; Wed, 4 Aug 1999 08:01:09 -0400 Received: from apache4.btv.ibm.com (schuld@localhost) by apache4.btv.ibm.com (8.8.8/8.8.8) with ESMTP id IAA77610 for ; Wed, 4 Aug 1999 08:01:29 -0400 Message-Id: <199908041201.IAA77610@apache4.btv.ibm.com> X-Mailer: exmh version 2.0.3 3/23/99 To: gcc@gcc.gnu.org X-uri: http://www.chips.ibm.com/products/foundry/ X-Note-Format: RFC822 Subject: Build report for rs6000-ibm-aix4.2.1.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Aug 1999 08:01:29 -0400 From: "David W. Schuler" I have successfully compiled gcc version 2.95 19990728 (release) for rs6000-ibm-aix4.2.1.0. Counting all warnings, there are 3 warnings in stage3 of this bootstrap. Number of warnings per file: 2 cxxmain.c 1 ../../../gcc/gcc/f/com.c Number of warning types: 2 assignment discards qualifiers from pointer target type 1 unused parameter `???' From gcc-return-8785-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 12:55:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11798 invoked by alias); 4 Aug 1999 12:55:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11780 invoked from network); 4 Aug 1999 12:55:34 -0000 Received: from dialup096.albatross.co.nz (HELO loki.albatross.co.nz) (nobody@203.97.5.96) by egcs.cygnus.com with SMTP; 4 Aug 1999 12:55:34 -0000 Received: from localhost (psycho@localhost) by loki.albatross.co.nz (8.9.3/8.9.3) with ESMTP id AAA19384; Thu, 5 Aug 1999 00:55:58 +1200 X-Authentication-Warning: loki.albatross.co.nz: psycho owned process doing -bs Date: Thu, 5 Aug 1999 00:55:57 +1200 (NZST) From: Keith Duthie To: Philip Blundell cc: gcc@gcc.gnu.org Subject: Re: specs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 4 Aug 1999, Philip Blundell wrote: > If gcc is trying to pick up specs from your current directory, chances are > this is because you have some environment variable telling it to do so. Even > if you tell it not to use directories you will lose if you happen to have a > *file* called `specs'. Perhaps, but in no case that I know of do we want to read a directory to get the specs information. > I've never been especially convinced that following LIBRARY_PATH (or whatever > it is) to find the specs is desirable, in fact. I'm not, either. But presumably someone is. -- Understanding is a three edged sword. Do you *want* to get the point? http://www.albatross.co.nz/~psycho/ O- From gcc-return-8786-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 14:18:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27039 invoked by alias); 4 Aug 1999 14:18:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27021 invoked from network); 4 Aug 1999 14:18:39 -0000 Received: from timbuk-fddi.cray.com (HELO timbuk-e1.cray.com) (128.162.8.102) by egcs.cygnus.com with SMTP; 4 Aug 1999 14:18:39 -0000 Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by timbuk-e1.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id JAA14786 for ; Wed, 4 Aug 1999 09:18:37 -0500 (CDT) Received: from ironwood-e185.cray.com (root@ironwood-e185.cray.com [128.162.185.212]) by ledzep.cray.com (8.9.3/craymail-smart) with ESMTP id JAA6095239 for ; Wed, 4 Aug 1999 09:18:35 -0500 (CDT) Received: from sgi044.cray.com (sgi044 [128.162.195.55]) by ironwood-e185.cray.com (8.8.4/ASC-news-e1.0) with ESMTP id JAA29248 for ; Wed, 4 Aug 1999 09:18:34 -0500 (CDT) Received: from localhost by sgi044.cray.com (8.8.8/SGI-client.1.6) via ESMTP id JAA35657; Wed, 4 Aug 1999 09:18:33 -0500 (CDT) Date: Wed, 4 Aug 1999 09:18:32 -0500 From: James Beyer X-Sender: beyerj@sgi044.cray.com To: gcc@gcc.gnu.org Subject: mips-sgi-irix6.5 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII mips-sgi-irix6.5 Successful The build went relatively smoothly using gmake with the MIPSpro Compilers: Version 7.2.1 on: 8 194 MHZ IP25 Processors CPU: MIPS R10000 Processor Chip Revision: 2.6 FPU: MIPS R10010 Floating Point Chip Revision: 0.0 Main memory size: 512 Mbytes, 2-way interleaved Instruction cache size: 32 Kbytes Data cache size: 32 Kbytes I have only run minimal tests so far, with out the test suite. Congradulations on the improved mips support. Usually building for mips has been a major pain for me. thanks james From gcc-return-8787-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 14:45:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30372 invoked by alias); 4 Aug 1999 14:45:34 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30265 invoked from network); 4 Aug 1999 14:44:59 -0000 Received: from hell.obspm.fr (145.238.16.184) by egcs.cygnus.com with SMTP; 4 Aug 1999 14:44:59 -0000 Received: (from noar@localhost) by hell.obspm.fr (8.9.3/8.9.3) id QAA32045 for gcc@gcc.gnu.org; Wed, 4 Aug 1999 16:44:23 +0200 Date: Wed, 4 Aug 1999 16:44:23 +0200 From: Arnaud Abrassart Message-Id: <199908041444.QAA32045@hell.obspm.fr> To: gcc@gcc.gnu.org Subject: 2.95 alphaev56-unknown-linux-gnu Successful /usr/local/gcc295inst/gcc-2.95/config.guess gave: alphaev56-unknown-linux-gnu I Just compiled and ran my transfer code...No pb so far ... From gcc-return-8788-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 15:10:40 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3142 invoked by alias); 4 Aug 1999 15:10:39 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3115 invoked from network); 4 Aug 1999 15:10:35 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by egcs.cygnus.com with SMTP; 4 Aug 1999 15:10:35 -0000 Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id LAA77488; Wed, 4 Aug 1999 11:10:14 -0400 Received: from marc.watson.ibm.com (marc.watson.ibm.com [9.2.176.11]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id LAA07506; Wed, 4 Aug 1999 11:09:59 -0400 Received: from localhost by marc.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA40536; Wed, 4 Aug 1999 11:09:14 -0400 Message-Id: <9908041509.AA40536@marc.watson.ibm.com> To: Patrick Lerda Cc: "'gcc@gcc.gnu.org'" Subject: Re: PowerPC gcc 2.8.1 generate wrong code while compiling linux 2.2.9 In-Reply-To: Message from Patrick Lerda of "Wed, 04 Aug 1999 09:48:07 +0200." <3AC9A1611DF4D211AA8E00105AA56D8A048A8F@IIS000.microdata.fr> Date: Wed, 04 Aug 1999 11:09:13 -0400 From: David Edelsohn gcc-2.8.1 probably is the least reliable compiler for PowerPC. I would suggest egcs-1.1.2 or gcc-2.95. The latest, supported GCC RPMs for Linux/PPC probably are your best bet. David From gcc-return-8789-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 15:34:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6446 invoked by alias); 4 Aug 1999 15:34:49 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6430 invoked from network); 4 Aug 1999 15:34:46 -0000 Received: from mailfw2.ford.com (136.1.1.27) by egcs.cygnus.com with SMTP; 4 Aug 1999 15:34:46 -0000 Received: by mailfw2.ford.com id LAA21807 (InterLock SMTP Gateway 4.2 for gcc@gcc.gnu.org); Wed, 4 Aug 1999 11:34:42 -0400 Message-Id: <199908041534.LAA21807@mailfw2.ford.com> Received: by mailfw2.ford.com (Internal Mail Agent-1); Wed, 4 Aug 1999 11:34:42 -0400 Date: Wed, 04 Aug 1999 11:34:37 -0400 From: Mark Hennes Reply-To: mhennes@ford.com Organization: Ford Motor Company X-Mailer: Mozilla 4.04C-4.04f4.0 [en] (X11; I; IRIX64 6.5 IP30) Mime-Version: 1.0 To: gcc@gcc.gnu.org Subject: GCC2.95 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Successfully built and installed gcc-2.95. It has not been tested however. mips-sgi-irix6.5 -- Mark Hennes CVSP Development ECC, 210-4b (313)-248-1225 From gcc-return-8790-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 16:08:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11775 invoked by alias); 4 Aug 1999 16:08:57 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11760 invoked from network); 4 Aug 1999 16:08:54 -0000 Received: from cs3.ecok.edu (198.11.4.200) by egcs.cygnus.com with SMTP; 4 Aug 1999 16:08:54 -0000 Subject: failure on OSR 5.0.X To: gcc@gcc.gnu.org Date: Wed, 4 Aug 1999 11:09:50 -0500 (CDT) From: Bill Walker X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <9908041109.aa08901@cs3.ecok.EDU> I received this from the mailing list, which greatly pisses me off. The damned ORBS folks seem to have cyberjacked me, and frankly I really resent it. I do understand the need, but I also really wonder who in the hell appointed ORBS to be the world's cypercops. As to "fixing the mail server", it is an old SCO 3.2v4.2 box, and replacing it is out of the question. It is running the latest smail, and it seems that smail does not measure up to ORBS standards, whatever they are. ORBS claims to apply 17 tests, but sends a report only after the first failure, so everytime I fix the thing ORBS just runs a different test and zaps me again. Grrr. In other news, I was trying to report failure with OSR 5.0.X as detailed below. 73 de Bill W5GFE > > Hi. This is the qmail-send program at egcs.cygnus.com. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > : > > Your mail server is listed in an RBL, so I will not accept mail from you. > You should contact your local mail administrators and get your mail > server fixed. For more information about my use of the RBLs, see > http://gcc.gnu.org/lists.html > > The IP number that I'm denying mail from is 198.11.4.1 > The RBL that you're on is ORBS RBL. See: > http://www.orbs.org/verify.cgi?address=198.11.4.1 > for more information about this RBL and why you are on it. [snip] > --- Below this line is a copy of the message. > > > This has failed on both 5.0.2 and 5.0.4 in the same place. > > > > make[5]: Entering directory `/usr15/bw/gcc-2.95/gcc' > ./xgcc -B./ -B/usr/local/i586-pc-sco3.2v5.0.2/bin/ -I/usr/local/i586-pc-sco3.2v5.0.2/include -O2 -DIN_GCC -O2 -g -O2 -I./include -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -g -O2 -I. -I. -I./config -I./../include \ > -c -fexceptions ./cp/exception.cc > xgcc: Internal compiler error: program as got fatal signal 11 > make[5]: *** [exception.o] Error 1 > make[5]: Leaving directory `/usr15/bw/gcc-2.95/gcc' > make[4]: *** [libgcc2.a] Error 1 > make[4]: Leaving directory `/usr15/bw/gcc-2.95/gcc' > make[3]: *** [stmp-multilib-sub] Error 2 > make[3]: Leaving directory `/usr15/bw/gcc-2.95/gcc' > make[2]: *** [stmp-multilib] Error 1 > make[2]: Leaving directory `/usr15/bw/gcc-2.95/gcc' > make[1]: *** [bootstrap] Error 2 > make[1]: Leaving directory `/usr15/bw/gcc-2.95/gcc' > make: *** [bootstrap] Error 2 > > -- Bill Walker Ph.D. Professor and Chairman Department of Computer Science East Central University Ada, Oklahoma 74820-6899 580 332 8000 x 594 (direct) 580 310 5594 bw@cs.ecok.edu From gcc-return-8791-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 16:15:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12908 invoked by alias); 4 Aug 1999 16:15:49 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12871 invoked from network); 4 Aug 1999 16:15:40 -0000 Received: from newton.math.purdue.edu (root@128.210.3.6) by egcs.cygnus.com with SMTP; 4 Aug 1999 16:15:40 -0000 Received: from polya.math.purdue.edu (lucier@polya.math.purdue.edu [128.210.3.194]) by newton.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.3) with ESMTP id LAA00642; Wed, 4 Aug 1999 11:15:22 -0500 (EST) Received: (from lucier@localhost) by polya.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.1) id LAA28653; Wed, 4 Aug 1999 11:15:21 -0500 (EST) Date: Wed, 4 Aug 1999 11:15:21 -0500 (EST) From: Brad Lucier Message-Id: <199908041615.LAA28653@polya.math.purdue.edu> To: gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: big slowdown in egcs-1.1.2->gcc-2.95 on alpha Cc: lucier@math.purdue.edu, staff@math.purdue.edu, jlee@math.purdue.edu, hosking@cs.purdue.edu, wilker@math.purdue.edu X-Sun-Charset: US-ASCII I'm running a Genetic Programming system, where compile times are as important as run times. I noticed that gcc-2.95 is a *lot* slower than egcs-1.1.2 on my alpha-ev6 running Red Hat 6.0 with binutils 2.9.5.0.3 Here are some typical times: egcs-1.1.2: /usr/bin/time /usr/bin/gcc -mcpu=ev6 -fPIC -O1 -c -D___DYNAMIC -D___SINGLE_HOST system.c 106.60user 0.17system 0:13.49elapsed 790%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (2248major+8092minor)pagefaults 0swaps gcc-2.9.5: /usr/bin/time /export/u10/gcc-2.95/bin/gcc -mcpu=ev6 -fPIC -O1 -c -D___DYNAMIC -D___SINGLE_HOST system.c 250.77user 0.24system 0:31.59elapsed 794%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (2330major+15298minor)pagefaults 0swaps (The user and system times on this box are too big by a factor of 8.) I try to be an independent guy---I installed a test version compiled with -pg, but gprof on my platform dumps core (both the original one and the one with 2.9.5.0.3) so that isn't much help. Any suggestions? Anybody else notice this? Brad Lucier lucier@math.purdue.edu From gcc-return-8792-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 17:00:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19616 invoked by alias); 4 Aug 1999 17:00:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19590 invoked from network); 4 Aug 1999 17:00:22 -0000 Received: from host162.nashville.com (HELO rjlhome.sco.com) (207.65.231.162) by egcs.cygnus.com with SMTP; 4 Aug 1999 17:00:22 -0000 Received: (from robertl@localhost) by rjlhome.sco.com (8.8.8/SCO5) id LAA05824; Wed, 4 Aug 1999 11:59:32 -0500 (CDT) Date: Wed, 4 Aug 1999 11:59:32 -0500 From: Robert Lipe To: Bill Walker Cc: gcc@gcc.gnu.org Subject: Re: failure on OSR 5.0.X Message-ID: <19990804115932.B20745@rjlhome.sco.com> References: <9908041109.aa08901@cs3.ecok.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95us In-Reply-To: <9908041109.aa08901@cs3.ecok.EDU>; from Bill Walker on Wed, Aug 04, 1999 at 11:09:50AM -0500 > I received this from the mailing list, which greatly pisses me off. > The damned ORBS folks seem to have cyberjacked me, and frankly I I can't help with that. Sorry. > In other news, I was trying to report failure with OSR 5.0.X as > detailed below. This, however, is interesting. > > This has failed on both 5.0.2 and 5.0.4 in the same place. Frightening. > > make[5]: Entering directory `/usr15/bw/gcc-2.95/gcc' > > ./xgcc -B./ -B/usr/local/i586-pc-sco3.2v5.0.2/bin/ -I/usr/local/i586-pc-sco3.2v5.0.2/include -O2 -DIN_GCC -O2 -g -O2 -I./include -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -g -O2 -I. -I. -I./config -I./../include \ > > -c -fexceptions ./cp/exception.cc > > xgcc: Internal compiler error: program as got fatal signal 11 > > make[5]: *** [exception.o] Error 1 What were the exact configure and make lines issued? Could you issue that command (cut and paste is your friend) but add "-v" and "--save-temps" to the line? This should give you an `exception.s'. Then issue the 'as' command that was displayed in the '-v' output. It will probably look something like this: /usr/ccs/bin/as -b elf -Ea,XPG4PLUS,ELF -Qn -o exception.o exception.s If the assembler drops core on that file, please send me exception.s I'm trying to figure out if EGCS is generating nonsense or if my 5.0.5 assembler has a bug fix that your 5.0.[24] assembler doesn't. If I can assemble that file then that tells us your assemblers are broken. If I can't assemble it, then we have to figure out why EGCS is generating different output for the two of us. I have reports from another 5.0.4 user that this works so I'm quite puzzled at this point... RJL From gcc-return-8793-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 17:03:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20613 invoked by alias); 4 Aug 1999 17:03:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20595 invoked from network); 4 Aug 1999 17:03:13 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 4 Aug 1999 17:03:13 -0000 Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id NAA29562; Wed, 4 Aug 1999 13:03:07 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com by world.std.com (TheWorld/Spike-2.0) id AA25843; Wed, 4 Aug 1999 13:02:05 -0400 Received: (qmail 13767 invoked by uid 500); 4 Aug 1999 16:43:43 -0000 Date: 4 Aug 1999 16:43:43 -0000 Message-Id: <19990804164343.13766.qmail@deer> To: bw@cs3.ecok.EDU Cc: gcc@gcc.gnu.org Cc: craig@jcb-sc.com In-Reply-To: <9908041109.aa08901@cs3.ecok.EDU> (message from Bill Walker on Wed, 4 Aug 1999 11:09:50 -0500 (CDT)) Subject: Re: failure on OSR 5.0.X References: <9908041109.aa08901@cs3.ecok.EDU> >I do understand the need, but I also really wonder who in the hell appointed >ORBS to be the world's cypercops. Try reading all the info at before complaining out loud next time. tq vm, (burley) From gcc-return-8794-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 17:13:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22092 invoked by alias); 4 Aug 1999 17:13:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22077 invoked from network); 4 Aug 1999 17:13:19 -0000 Received: from c1000907-b.sttls1.wa.home.com (root@24.0.226.45) by egcs.cygnus.com with SMTP; 4 Aug 1999 17:13:19 -0000 Received: from localhost (mjc@localhost) by c1000907-b.sttls1.wa.home.com (8.6.12/8.6.9) with ESMTP id KAA21690 for ; Wed, 4 Aug 1999 10:13:17 -0700 Date: Wed, 4 Aug 1999 10:13:17 -0700 (PDT) From: Mark Crosland To: gcc@gcc.gnu.org Subject: Trying to build egcs-1.1.2 on dynix/sequent platform... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I am trying to build egcs-1.1.2 on a dynix/sequent platform. uname -a DYNIX/ptx engdevq1 4.0 V4.4.2 i386 untar the stuff ../configure --prefix=/users/markc/sw/egcs --enable-languages=c,c++ make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' LANGUAGES="c c++" bootstrap-lean gcc/collect2 is appearing to have problems resolving __sys_siglist,. Clues appreciated :) Thanks, Mark Crosland make[1]: Entering directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/libiberty' if [ x"no" = xyes ] && [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir CONFIG_FILES= CONFIG_HEADERS=config.h:config.in /bin/sh ./config.status creating config.h test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/argv.c -o pic/argv.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/argv.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/choose-temp.c -o pic/choose-temp.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/choose-temp.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/concat.c -o pic/concat.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/concat.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/cplus-dem.c -o pic/cplus-dem.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/cplus-dem.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/fdmatch.c -o pic/fdmatch.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/fdmatch.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/fnmatch.c -o pic/fnmatch.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/fnmatch.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/getopt.c -o pic/getopt.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/getopt.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/getopt1.c -o pic/getopt1.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/getopt1.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/getruntime.c -o pic/getruntime.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/getruntime.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/hex.c -o pic/hex.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/hex.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/floatformat.c -o pic/floatformat.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/floatformat.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/objalloc.c -o pic/objalloc.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/objalloc.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/obstack.c -o pic/obstack.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/obstack.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/pexecute.c -o pic/pexecute.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/pexecute.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/spaces.c -o pic/spaces.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/spaces.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/strerror.c -o pic/strerror.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/strerror.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/strsignal.c -o pic/strsignal.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/strsignal.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/xatexit.c -o pic/xatexit.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/xatexit.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/xexit.c -o pic/xexit.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/xexit.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/xmalloc.c -o pic/xmalloc.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/xmalloc.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/xstrdup.c -o pic/xstrdup.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/xstrdup.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/xstrerror.c -o pic/xstrerror.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/xstrerror.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/asprintf.c -o pic/asprintf.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/asprintf.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/basename.c -o pic/basename.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/basename.c test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/getpagesize.c -o pic/getpagesize.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/getpagesize.c "../../libiberty/getpagesize.c", line 80: warning: tokens ignored at end of directive line test x"no" != xyes || \ cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/vasprintf.c -o pic/vasprintf.o cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../libiberty/../include ../../libiberty/vasprintf.c rm -f libiberty.a ar cr libiberty.a \ argv.o choose-temp.o concat.o cplus-dem.o fdmatch.o fnmatch.o getopt.o getopt1.o getruntime.o hex.o floatformat.o objalloc.o obstack.o pexecute.o spaces.o strerror.o strsignal.o xatexit.o xexit.o xmalloc.o xstrdup.o xstrerror.o asprintf.o basename.o getpagesize.o vasprintf.o true libiberty.a f="asprintf.o basename.o getpagesize.o vasprintf.o "; \ case $f in \ *alloca.o*) f="$f xmalloc.o xexit.o" ;; \ esac; \ echo $f > needed-list echo argv.o choose-temp.o concat.o cplus-dem.o fdmatch.o fnmatch.o getopt.o getopt1.o getruntime.o hex.o floatformat.o objalloc.o obstack.o pexecute.o spaces.o strerror.o strsignal.o xatexit.o xexit.o xmalloc.o xstrdup.o xstrerror.o > required-list make[1]: Leaving directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/libiberty' make[1]: Entering directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/texinfo' make all-recursive make[2]: Entering directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/texinfo' Making all in intl make[3]: Entering directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/texinfo/intl' cc -c -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DGNULOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DLOCALE_ALIAS_PATH=\"/users/markc/sw/egcs/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../../../texinfo/intl -I../../../texinfo/lib -O ../../../texinfo/intl/intl-compat.c cc -c -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DGNULOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DLOCALE_ALIAS_PATH=\"/users/markc/sw/egcs/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../../../texinfo/intl -I../../../texinfo/lib -O ../../../texinfo/intl/bindtextdom.c cc -c -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DGNULOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DLOCALE_ALIAS_PATH=\"/users/markc/sw/egcs/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../../../texinfo/intl -I../../../texinfo/lib -O ../../../texinfo/intl/dcgettext.c cc -c -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DGNULOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DLOCALE_ALIAS_PATH=\"/users/markc/sw/egcs/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../../../texinfo/intl -I../../../texinfo/lib -O ../../../texinfo/intl/dgettext.c cc -c -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DGNULOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DLOCALE_ALIAS_PATH=\"/users/markc/sw/egcs/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../../../texinfo/intl -I../../../texinfo/lib -O ../../../texinfo/intl/gettext.c cc -c -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DGNULOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DLOCALE_ALIAS_PATH=\"/users/markc/sw/egcs/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../../../texinfo/intl -I../../../texinfo/lib -O ../../../texinfo/intl/finddomain.c cc -c -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DGNULOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DLOCALE_ALIAS_PATH=\"/users/markc/sw/egcs/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../../../texinfo/intl -I../../../texinfo/lib -O ../../../texinfo/intl/loadmsgcat.c cc -c -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DGNULOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DLOCALE_ALIAS_PATH=\"/users/markc/sw/egcs/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../../../texinfo/intl -I../../../texinfo/lib -O ../../../texinfo/intl/localealias.c cc -c -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DGNULOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DLOCALE_ALIAS_PATH=\"/users/markc/sw/egcs/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../../../texinfo/intl -I../../../texinfo/lib -O ../../../texinfo/intl/textdomain.c cc -c -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DGNULOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DLOCALE_ALIAS_PATH=\"/users/markc/sw/egcs/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../../../texinfo/intl -I../../../texinfo/lib -O ../../../texinfo/intl/l10nflist.c cc -c -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DGNULOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -DLOCALE_ALIAS_PATH=\"/users/markc/sw/egcs/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../../../texinfo/intl -I../../../texinfo/lib -O ../../../texinfo/intl/explodename.c rm -f libintl.a ar cru libintl.a intl-compat.o bindtextdom.o dcgettext.o dgettext.o gettext.o finddomain.o loadmsgcat.o localealias.o textdomain.o l10nflist.o explodename.o true libintl.a make[3]: Leaving directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/texinfo/intl' Making all in lib make[3]: Entering directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/texinfo/lib' cc -DHAVE_CONFIG_H -I. -I../../../texinfo/lib -I.. -I../intl -O -c ../../../texinfo/lib/getopt.c cc -DHAVE_CONFIG_H -I. -I../../../texinfo/lib -I.. -I../intl -O -c ../../../texinfo/lib/getopt1.c cc -DHAVE_CONFIG_H -I. -I../../../texinfo/lib -I.. -I../intl -O -c ../../../texinfo/lib/xmalloc.c cc -DHAVE_CONFIG_H -I. -I../../../texinfo/lib -I.. -I../intl -O -c ../../../texinfo/lib/xstrdup.c cc -DHAVE_CONFIG_H -I. -I../../../texinfo/lib -I.. -I../intl -O -c ../../../texinfo/lib/alloca.c rm -f libtxi.a ar cru libtxi.a getopt.o getopt1.o xmalloc.o xstrdup.o alloca.o true libtxi.a make[3]: Leaving directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/texinfo/lib' Making all in makeinfo make[3]: Entering directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/texinfo/makeinfo' cc -DHAVE_CONFIG_H -I. -I../../../texinfo/makeinfo -I.. -I../../../texinfo/lib -I../intl -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -O -c ../../../texinfo/makeinfo/makeinfo.c cc -DHAVE_CONFIG_H -I. -I../../../texinfo/makeinfo -I.. -I../../../texinfo/lib -I../intl -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -O -c ../../../texinfo/makeinfo/multi.c cc -O -o makeinfo makeinfo.o multi.o ../lib/libtxi.a ../intl/libintl.a make[3]: Leaving directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/texinfo/makeinfo' Making all in util make[3]: Entering directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/texinfo/util' cc -DHAVE_CONFIG_H -I. -I../../../texinfo/util -I.. -I../../../texinfo/lib -I../intl -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -O -c ../../../texinfo/util/install-info.c cc -O -o install-info install-info.o ../lib/libtxi.a ../intl/libintl.a cc -DHAVE_CONFIG_H -I. -I../../../texinfo/util -I.. -I../../../texinfo/lib -I../intl -DLOCALEDIR=\"/users/markc/sw/egcs/share/locale\" -O -c ../../../texinfo/util/texindex.c cc -O -o texindex texindex.o ../lib/libtxi.a ../intl/libintl.a make[3]: Leaving directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/texinfo/util' make[2]: Leaving directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/texinfo' make[1]: Leaving directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/texinfo' Bootstrapping the compiler make[1]: Entering directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/gcc' make CC="cc" libdir=/users/markc/sw/egcs/lib LANGUAGES="c " make[2]: Entering directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/gcc' cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config \ -DGCC_INCLUDE_DIR=\"/users/markc/sw/egcs/lib/gcc-lib/i386-sequent-sysv4/egcs-2.91.66/include\" \ -DGPLUSPLUS_INCLUDE_DIR=\"/users/markc/sw/egcs/include/g++\" \ -DOLD_GPLUSPLUS_INCLUDE_DIR=\"/users/markc/sw/egcs/lib/g++-include\" \ -DLOCAL_INCLUDE_DIR=\"/usr/local/include\" \ -DCROSS_INCLUDE_DIR=\"/users/markc/sw/egcs/i386-sequent-sysv4/sys-include\" \ -DTOOL_INCLUDE_DIR=\"/users/markc/sw/egcs/i386-sequent-sysv4/include\" \ -c `echo ../../gcc/cccp.c | sed 's,^\./,,'` cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -c ../../gcc/cexp.c "cexp.y", line 1047: portability warning: semantics of ">>" change in ANSI C; use explicit cast "cexp.y", line 1049: portability warning: semantics of ">>" change in ANSI C; use explicit cast cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/version.c cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config \ -DPREFIX=\"/users/markc/sw/egcs\" \ -c `echo ../../gcc/prefix.c | sed 's,^\./,,'` "../../gcc/prefix.c", line 258: warning: improper pointer/integer combination: op "=" cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/obstack.c cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config \ -c `echo ../../gcc/alloca.c | sed 's,^\./,,'` true cc -DIN_GCC -g -DHAVE_CONFIG_H -o cccp cccp.o cexp.o prefix.o \ version.o obstack.o alloca.o rm -f cpp ln cccp cpp cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/gencheck.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o gencheck \ gencheck.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./gencheck > tmp-check.h ../../gcc/move-if-change tmp-check.h tree-check.h touch s-check cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -c ../../gcc/c-parse.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/c-lang.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/gengenrtl.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o gengenrtl \ gengenrtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./gengenrtl tmp-genrtl.h tmp-genrtl.c ../../gcc/move-if-change tmp-genrtl.h genrtl.h ../../gcc/move-if-change tmp-genrtl.c genrtl.c touch s-genrtl cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/c-lex.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant "../../gcc/c-lex.c", line 562: warning: statement not reached "../../gcc/c-lex.c", line 1940: portability warning: semantics of ">=" change in ANSI C; use explicit cast cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/c-pragma.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/c-decl.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant "../../gcc/c-decl.c", line 6173: portability warning: semantics of ">" change in ANSI C; use explicit cast cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/gencodes.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/rtl.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/bitmap.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/print-rtl.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o gencodes \ gencodes.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./gencodes ../../gcc/config/i386/i386.md > tmp-codes.h ../../gcc/move-if-change tmp-codes.h insn-codes.h touch s-codes cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/c-typeck.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant "../../gcc/c-typeck.c", line 1041: portability warning: semantics of "<" change in ANSI C; use explicit cast "../../gcc/c-typeck.c", line 2470: portability warning: semantics of ">" change in ANSI C; use explicit cast "../../gcc/c-typeck.c", line 2472: portability warning: semantics of "<=" change in ANSI C; use explicit cast "../../gcc/c-typeck.c", line 2594: portability warning: semantics of "<" change in ANSI C; use explicit cast "../../gcc/c-typeck.c", line 4887: portability warning: semantics of "<" change in ANSI C; use explicit cast cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/c-convert.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/c-aux-info.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/c-common.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/c-iterate.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/genattr.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o genattr \ genattr.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./genattr ../../gcc/config/i386/i386.md > tmp-attr.h ../../gcc/move-if-change tmp-attr.h insn-attr.h touch s-attr cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/genconfig.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o genconfig \ genconfig.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./genconfig ../../gcc/config/i386/i386.md > tmp-config.h ../../gcc/move-if-change tmp-config.h insn-config.h touch s-config cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config \ -DTARGET_NAME=\"i386-sequent-sysv4\" \ -c `echo ../../gcc/toplev.c | sed 's,^\./,,'` "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/tree.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/print-tree.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/stor-layout.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/fold-const.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant "../../gcc/fold-const.c", line 1544: portability warning: semantics of ">" change in ANSI C; use explicit cast "../../gcc/fold-const.c", line 2154: portability warning: trigraph sequence replaced cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/genflags.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o genflags \ genflags.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./genflags ../../gcc/config/i386/i386.md > tmp-flags.h ../../gcc/move-if-change tmp-flags.h insn-flags.h touch s-flags cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/function.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/stmt.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/except.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant "../../gcc/except.c", line 1956: warning: old-style definition hides prototype declaration: set_exception_lang_code "../../gcc/except.c", line 1957: warning: type does not match prototype declaration: code Calls before this definition may truncate the argument value "../../gcc/except.c", line 1963: warning: old-style definition hides prototype declaration: set_exception_version_code "../../gcc/except.c", line 1964: warning: type does not match prototype declaration: code Calls before this definition may truncate the argument value cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/expr.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant "../../gcc/expr.c", line 11165: portability warning: semantics of "<" change in ANSI C; use explicit cast cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/calls.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/expmed.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant "../../gcc/expmed.c", line 2454: warning: argument is incompatible with prototype: arg #7 "../../gcc/expmed.c", line 2454: warning: argument is incompatible with prototype: arg #8 "../../gcc/expmed.c", line 2454: warning: argument is incompatible with prototype: arg #9 "../../gcc/expmed.c", line 2454: warning: argument is incompatible with prototype: arg #10 "../../gcc/expmed.c", line 2462: warning: argument is incompatible with prototype: arg #7 "../../gcc/expmed.c", line 2462: warning: argument is incompatible with prototype: arg #8 "../../gcc/expmed.c", line 2462: warning: argument is incompatible with prototype: arg #9 "../../gcc/expmed.c", line 2462: warning: argument is incompatible with prototype: arg #10 cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/explow.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/optabs.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/varasm.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant "../../gcc/varasm.c", line 977: warning: improper pointer/integer combination: op "=" "../../gcc/varasm.c", line 1468: warning: improper pointer/integer combination: op "=" cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/rtlanal.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/emit-rtl.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config genrtl.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/real.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/regmove.c "../../gcc/regmove.c", line 514: warning: statement not reached cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/dbxout.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/sdbout.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/dwarfout.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/dwarf2out.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant "../../gcc/dwarf2out.c", line 1029: warning: initializer does not fit: -1 cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/xcoffout.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/alias.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/integrate.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/jump.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/cse.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/loop.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/unroll.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/flow.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/stupid.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/combine.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/varray.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/regclass.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/local-alloc.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/global.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/reload.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/reload1.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/caller-save.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/gcse.c "../../gcc/gcse.c", line 4175: warning: initializer does not fit: -1 "../../gcc/gcse.c", line 4216: warning: initializer does not fit: -1 cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/genpeep.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o genpeep \ genpeep.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./genpeep ../../gcc/config/i386/i386.md > tmp-peep.c ../../gcc/move-if-change tmp-peep.c insn-peep.c touch s-peep cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -c insn-peep.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/reorg.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/sched.c "../../gcc/sched.c", line 1758: warning: statement not reached cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/final.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/recog.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/reg-stack.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/genopinit.c "../../gcc/genopinit.c", line 72: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 73: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 74: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 74: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 75: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 76: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 76: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 77: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 77: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 78: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 78: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 79: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 79: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 87: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 88: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 93: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 94: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 103: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 104: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 105: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 106: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 107: portability warning: dubious escape: \% "../../gcc/genopinit.c", line 108: portability warning: dubious escape: \% cc -DIN_GCC -g -DHAVE_CONFIG_H -o genopinit \ genopinit.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./genopinit ../../gcc/config/i386/i386.md > tmp-opinit.c ../../gcc/move-if-change tmp-opinit.c insn-opinit.c touch s-opinit cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -c insn-opinit.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/genrecog.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o genrecog \ genrecog.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./genrecog ../../gcc/config/i386/i386.md > tmp-recog.c ../../gcc/move-if-change tmp-recog.c insn-recog.c touch s-recog cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -c insn-recog.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/genextract.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o genextract \ genextract.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./genextract ../../gcc/config/i386/i386.md > tmp-extract.c ../../gcc/move-if-change tmp-extract.c insn-extract.c touch s-extract cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -c insn-extract.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/genoutput.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o genoutput \ genoutput.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./genoutput ../../gcc/config/i386/i386.md > tmp-output.c ../../gcc/move-if-change tmp-output.c insn-output.c touch s-output cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -c insn-output.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/genemit.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o genemit \ genemit.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./genemit ../../gcc/config/i386/i386.md > tmp-emit.c ../../gcc/move-if-change tmp-emit.c insn-emit.c touch s-emit cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -c insn-emit.c "insn-emit.c", line 47: warning: end-of-loop code not reached "insn-emit.c", line 80: warning: end-of-loop code not reached "insn-emit.c", line 113: warning: end-of-loop code not reached "insn-emit.c", line 149: warning: end-of-loop code not reached "insn-emit.c", line 189: warning: end-of-loop code not reached "insn-emit.c", line 229: warning: end-of-loop code not reached "insn-emit.c", line 274: warning: end-of-loop code not reached "insn-emit.c", line 318: warning: end-of-loop code not reached "insn-emit.c", line 362: warning: end-of-loop code not reached "insn-emit.c", line 408: warning: end-of-loop code not reached "insn-emit.c", line 439: warning: end-of-loop code not reached "insn-emit.c", line 470: warning: end-of-loop code not reached "insn-emit.c", line 1209: warning: end-of-loop code not reached "insn-emit.c", line 1392: warning: end-of-loop code not reached "insn-emit.c", line 2049: warning: end-of-loop code not reached "insn-emit.c", line 2085: warning: end-of-loop code not reached "insn-emit.c", line 2111: warning: end-of-loop code not reached "insn-emit.c", line 2209: warning: end-of-loop code not reached "insn-emit.c", line 2235: warning: end-of-loop code not reached "insn-emit.c", line 2261: warning: end-of-loop code not reached "insn-emit.c", line 2836: warning: end-of-loop code not reached "insn-emit.c", line 2860: warning: end-of-loop code not reached "insn-emit.c", line 3146: warning: end-of-loop code not reached "insn-emit.c", line 3250: warning: end-of-loop code not reached "insn-emit.c", line 3366: warning: end-of-loop code not reached "insn-emit.c", line 4422: warning: end-of-loop code not reached "insn-emit.c", line 4484: warning: end-of-loop code not reached "insn-emit.c", line 4567: warning: end-of-loop code not reached "insn-emit.c", line 4643: warning: end-of-loop code not reached "insn-emit.c", line 4701: warning: end-of-loop code not reached "insn-emit.c", line 4825: warning: end-of-loop code not reached "insn-emit.c", line 4875: warning: end-of-loop code not reached "insn-emit.c", line 4957: warning: end-of-loop code not reached "insn-emit.c", line 5014: warning: end-of-loop code not reached "insn-emit.c", line 5122: warning: end-of-loop code not reached "insn-emit.c", line 5232: warning: end-of-loop code not reached "insn-emit.c", line 5248: warning: end-of-loop code not reached "insn-emit.c", line 5364: warning: end-of-loop code not reached "insn-emit.c", line 5380: warning: end-of-loop code not reached "insn-emit.c", line 5496: warning: end-of-loop code not reached "insn-emit.c", line 5512: warning: end-of-loop code not reached "insn-emit.c", line 5626: warning: end-of-loop code not reached "insn-emit.c", line 5821: warning: end-of-loop code not reached "insn-emit.c", line 5851: warning: end-of-loop code not reached cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/profile.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/genattrtab.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o genattrtab \ genattrtab.o rtl.o bitmap.o print-rtl.o rtlanal.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` if cmp -s Makefile ../../gcc/config/i386/i386.md; \ then \ echo Using ; \ cp tmp-attrtab.c; \ else \ ./genattrtab ../../gcc/config/i386/i386.md > tmp-attrtab.c; \ fi ../../gcc/move-if-change tmp-attrtab.c insn-attrtab.c touch s-attrtab cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config -c insn-attrtab.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/config/i386/i386.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/getpwd.c cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/convert.c "../../gcc/tree.h", line 332: portability warning: macro replacement within a character constant "../../gcc/tree.h", line 333: portability warning: macro replacement within a character constant "../../gcc/convert.c", line 261: portability warning: semantics of ">=" change in ANSI C; use explicit cast "../../gcc/convert.c", line 264: portability warning: semantics of ">=" change in ANSI C; use explicit cast "../../gcc/convert.c", line 284: portability warning: semantics of ">" change in ANSI C; use explicit cast "../../gcc/convert.c", line 284: portability warning: semantics of ">" change in ANSI C; use explicit cast cc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/dyn-string.c cc -DIN_GCC -g -DHAVE_CONFIG_H -o cc1 c-parse.o c-lang.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-iterate.o toplev.o version.o tree.o print-tree.o stor-layout.o fold-const.o function.o stmt.o except.o expr.o calls.o expmed.o explow.o optabs.o varasm.o rtl.o print-rtl.o rtlanal.o emit-rtl.o genrtl.o real.o regmove.o dbxout.o sdbout.o dwarfout.o dwarf2out.o xcoffout.o bitmap.o alias.o integrate.o jump.o cse.o loop.o unroll.o flow.o stupid.o combine.o varray.o regclass.o local-alloc.o global.o reload.o reload1.o caller-save.o gcse.o insn-peep.o reorg.o sched.o final.o recog.o reg-stack.o insn-opinit.o insn-recog.o insn-extract.o insn-output.o insn-emit.o profile.o insn-attrtab.o i386.o getpwd.o convert.o dyn-string.o obstack.o alloca.o cc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config \ -DTARGET_MACHINE=\"i386-sequent-sysv4\" \ -c `echo ../../gcc/collect2.c | sed 's,^\./,,'` "../../gcc/collect2.c", line 1588: undefined symbol: _sys_siglist "../../gcc/collect2.c", line 1588: cannot dereference non-pointer type make[2]: *** [collect2.o] Error 1 make[2]: Leaving directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/gcc' make[1]: *** [bootstrap-lean] Error 2 make[1]: Leaving directory `/users/markc/sw/egcs/egcs-1.1.2/objdir/gcc' make: *** [bootstrap-lean] Error 2 From gcc-return-8795-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 18:02:40 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28392 invoked by alias); 4 Aug 1999 18:02:24 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28363 invoked from network); 4 Aug 1999 18:02:14 -0000 Received: from paris.ics.uci.edu (mmdf@128.195.1.50) by egcs.cygnus.com with SMTP; 4 Aug 1999 18:02:14 -0000 Received: from star.ics.uci.edu by paris.ics.uci.edu id aa28869; 4 Aug 99 10:51 PDT Date: Wed, 4 Aug 1999 10:51:28 -0700 (PDT) From: Radu Cornea To: Mike Stump cc: gcc@gcc.gnu.org Subject: Re: GCC questions In-Reply-To: <199908040034.RAA23418@kankakee.wrs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >>On Tue, 3 Aug 1999, Mike Stump wrote: > > Date: Tue, 3 Aug 1999 16:57:50 -0700 (PDT) > > From: Radu Cornea > ... > > 5. I am asking these questions because I need to solve this problem in gcc: > > in some cases, gcc transforms initial structured code into unstructured > > code. This happens for example for if statements that have as condition > > logical OR (||) or AND (&&) expressions. In order to generate structured > > code, the then-statement have to be duplicated (as many times as the number > > of ORs or ANDs). For this, i need to save somehow the then-statement tree > > when it is generated and duplicate it (and of course, the jumps need to be > > changed). > > Ok, too bad you didn't say exactly what you wanted to do. Sounds like > it is mostly outside the scope of compilation though. We can give > better answers to your question, if the question is the right > question. Tell us what you really want to do... > > I think what you want is an full function ast, that preserves > constructs like if and while. If that is it, then if you can use just > C++, then you might consider turning on the template code everywhere, > and munching on it instead. In that style of code we preserve things > like: > > DEFTREECODE (DECL_STMT, "decl_stmt", 'e', 3) > DEFTREECODE (IF_STMT, "if_stmt", 'e', 3) > DEFTREECODE (FOR_STMT, "for_stmt", 'e', 4) > DEFTREECODE (WHILE_STMT, "while_stmt", 'e', 2) > DEFTREECODE (DO_STMT, "do_stmt", 'e', 2) > DEFTREECODE (RETURN_STMT, "return_stmt", 'e', 1) > DEFTREECODE (BREAK_STMT, "break_stmt", 'e', 0) > DEFTREECODE (CONTINUE_STMT, "continue_stmt", 'e', 0) > DEFTREECODE (SWITCH_STMT, "switch_stmt", 'e', 2) > DEFTREECODE (GOTO_STMT, "goto_stmt", 'e', 1) > > directly, and you can the walk that code and do what you want. But > since I don't know what you want to do, I don't know if this is a > solution to what you want to do. > I will try to explain what I am trying to do. We are working here at a compiler that uses gcc (a modified version for generating three-address code). Some optimizations and scheduling techniques that we use work only if the code is what we call "structured". In some situations, gcc transforms "structured code" into "unstructured". I will explain below what we mean by that. For e.g., for the C code: ... if (a||b) ; else ; ; ... (x, y and z are statements, a and b are expressions) gcc generates something like this: | / \ / This is what we call | / \ "unstructured code" [x] [y] \ / \ / | [z] | We want to get a code like this: | / \ / / / \ This is what we call [x] [x] [y] "structured code" \ | / i.e. can be viewed \ | / as an if inside \ |/ another if. \| | [z] | So, the [x] statement must be duplicated. This problem happens only when the if condition is a OR or AND logical expression (it is an optimization made by gcc). If you have any idea how could I modify gcc to get that kind of code, I would appreciate very much. Thanks, Radu. -- Radu Cornea Graduate Student Information & Computer Science University of California - Irvine E-mail: radu@ics.uci.edu From gcc-return-8796-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 18:17:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31276 invoked by alias); 4 Aug 1999 18:17:01 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31236 invoked from network); 4 Aug 1999 18:16:56 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 4 Aug 1999 18:16:56 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id MAA10992; Wed, 4 Aug 1999 12:15:12 -0600 X-Mailer: exmh version 2.0.2 To: Mark Crosland cc: gcc@gcc.gnu.org Subject: Re: Trying to build egcs-1.1.2 on dynix/sequent platform... Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 04 Aug 1999 10:13:17 PDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Aug 1999 12:15:11 -0600 Message-ID: <10989.933790511@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > > Hello, I am trying to build egcs-1.1.2 on a dynix/sequent platform. > uname -a > DYNIX/ptx engdevq1 4.0 V4.4.2 i386 Nobody's had success with a dynix/sequent system that I'm aware of. You'll have to do some debugging/fixing yourself. We would greatly appreciate it if you could forward any fixes to the gcc-patches list. Apparently dynix's handling of sys_siglist is different from most other systems, which may require you to define SYS_SIGLIST_DECLARED or NO_SYS_SIGLIST to change the compiler's strategy for handling the signal list variable. jeff From gcc-return-8797-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 18:48:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3410 invoked by alias); 4 Aug 1999 18:48:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3363 invoked from network); 4 Aug 1999 18:48:14 -0000 Received: from unknown (HELO mad.lared.es) (194.75.94.2) by egcs.cygnus.com with SMTP; 4 Aug 1999 18:48:14 -0000 eceived: by mad.lared.es with MERCUR-SMTP/POP3-Server (v2.10) for at Wed, 4 Aug 99 12:40:22 +0200 To: nainoe13@teloz.latrobe.edu.au From: nainoe13@teloz.latrobe.edu.au (Boookss) Comments: Authenticated sender is Subject: FREE!!!....THOUSANDS OF BOOKS! Message-Id: <199908042645MAA28668@moiunuis.es> Date: Wed, 4 Aug 99 12:40:22 +0200 THOUSANDS OF FREE BOOKS TO DOWNLOAD. OUT OF THE THOUSANDS OF FREE BOOKS ON THE WEB THERE IS NOT ONE THAT WILL HOLD YOUR ATTENTION LIKE THIS ONE! THE IMMORTAL By J. J. Dewey For this and links to thousand s of other free books do not hit return but send reply to: 7more@bigfoot.com Write BOOKS in the subject area. The Immortal is the story of an average truth seeker who stumbles across a fascinating teacher, only to discover that the man is John the Revelator of Apocalypse fame, who has been wandering the earth incognito for the past 2000 years. John begins the task of teaching his new student the first of the Twelve Keys of Knowledge. The first question addressed in Book I is WHO OR WHAT AM I? The student gives all the standard answers...and they are all wrong. The lead character then realizes he is under the tutorage of no ordinary teacher and must apply himself in a quest for knowledge. WHAT OTHERS ARE SAYING ABOUT THE IMMORTAL My God man, you are one heaven sent story teller.... I just finished the Book. Whew... BT Just wanted to drop you a short note to tell you that I just got THE IMMORTAL and could not put it down. It is a fantastic book. I feel almost a sense of loss having finished it... CC I have finished reading Book 2, and I am totally amazed by the claims you make; I am fully aware that such high levels of information could never be invented or brought up by the human brain for a fictional story. WL I've recently finished reading The Immortal - Thank You! I've already told dozens and dozens of people, "If you read only one book this year, consider having it be The Immortal." And everyone that I've spoken with has had as enthusiastic response as Diane This is the best esoteric novel - by someone still living - I've come across so far. Book Review by Joseph Polansky, Editor of DIAMOND FIRE For this and links to thousand s of other free books do not hit return but send reply to: 7more@bigfoot.com Write BOOKS as the subject. For email removal - email 7more@bigfoot.com with the subject remove You will be removed immediately / From gcc-return-8798-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 18:54:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5368 invoked by alias); 4 Aug 1999 18:54:32 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5273 invoked from network); 4 Aug 1999 18:54:23 -0000 Received: from host162.nashville.com (HELO rjlhome.sco.com) (207.65.231.162) by egcs.cygnus.com with SMTP; 4 Aug 1999 18:54:23 -0000 Received: (from robertl@localhost) by rjlhome.sco.com (8.8.8/SCO5) id NAA13520; Wed, 4 Aug 1999 13:53:41 -0500 (CDT) Date: Wed, 4 Aug 1999 13:53:39 -0500 From: Robert Lipe To: Mark Crosland Cc: gcc@gcc.gnu.org Subject: Re: Trying to build egcs-1.1.2 on dynix/sequent platform... Message-ID: <19990804135339.D13367@rjlhome.sco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95us In-Reply-To: ; from Mark Crosland on Wed, Aug 04, 1999 at 10:13:17AM -0700 > Hello, I am trying to build egcs-1.1.2 on a dynix/sequent platform. > uname -a > DYNIX/ptx engdevq1 4.0 V4.4.2 i386 I think some of the issues you're facing were also tackled by a dude recently tackling the DG/UX. Things may be better on GCC 2.95. Certainly at least one of the warnings you're getting has been fixed since 1.1.2. > "../../gcc/collect2.c", line 1588: undefined symbol: _sys_siglist > "../../gcc/collect2.c", line 1588: cannot dereference non-pointer type Look in my_strignal in collect2.c. Apparently your system {is outsmarting|being outsmarted by} the code that renames/provides the sys_siglist[] array. RJL From gcc-return-8799-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 19:03:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9253 invoked by alias); 4 Aug 1999 19:03:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9222 invoked from network); 4 Aug 1999 19:03:01 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 4 Aug 1999 19:03:01 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id NAA11278; Wed, 4 Aug 1999 13:01:14 -0600 X-Mailer: exmh version 2.0.2 To: John Wehle cc: egcs@egcs.cygnus.com Subject: Re: try_split lossage Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 04 Aug 1999 03:49:23 EDT. <199908040749.DAA19869@jwlab.FEITH.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Aug 1999 13:01:14 -0600 Message-ID: <11275.933793274@upchuck.cygnus.com> From: Jeffrey A Law In message <199908040749.DAA19869@jwlab.FEITH.COM>you write: > The following is from dwarf2out_frame_debug: > > if (! RTX_FRAME_RELATED_P (insn)) > { > dwarf2out_stack_adjust (insn); > return; > } > > dwarf2out_stack_adjust has the comment: > > /* Check INSN to see if it looks like a push or a stack adjustment, and > make a note of it if it does. EH uses this information to find out how > much extra space it needs to pop off the stack. */ > > There seems to be the potential to break EH if RTX_FRAME_RELATED_P is > incorrect, however I'm somewhat naive when it comes to EH or dwarf2. Ah. I wasn't aware of that usage. But it's easy to handle -- if the insn we split was marked as frame related, the resulting insns must also be frame related. jeff From gcc-return-8800-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 19:20:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15323 invoked by alias); 4 Aug 1999 19:20:18 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15214 invoked from network); 4 Aug 1999 19:20:06 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 4 Aug 1999 19:20:06 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id MAA23826; Wed, 4 Aug 1999 12:20:03 -0700 (PDT) Received: by kankakee.wrs.com (SMI-8.6/SMI-SVR4) id MAA23634; Wed, 4 Aug 1999 12:20:03 -0700 Date: Wed, 4 Aug 1999 12:20:03 -0700 From: mrs@wrs.com (Mike Stump) Message-Id: <199908041920.MAA23634@kankakee.wrs.com> To: radu@ics.uci.edu Subject: Re: GCC questions Cc: gcc@gcc.gnu.org > Date: Wed, 4 Aug 1999 10:51:28 -0700 (PDT) > From: Radu Cornea > gcc generates something like this: > | > > / \ > / This is what we call > | / \ "unstructured code" > [x] [y] > \ / > \ / > | > [z] > | > We want to get a code like this: > | > > / \ > / > / / \ This is what we call > [x] [x] [y] "structured code" > \ | / i.e. can be viewed > \ | / as an if inside > \ |/ another if. > \| > | > [z] > | > So, the [x] statement must be duplicated. Well, I suspect you will find it best to work at the rtl level, write a new pass that restructures the code in the form you want, and then run your code on it. I suspect that something like copy_rtx is what you want. Your code then can also work on things like: if (a) goto b; if (b) goto b; y; goto z; b: b; z: z; with no extra effort. From gcc-return-8801-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 20:38:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32401 invoked by alias); 4 Aug 1999 20:38:08 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32361 invoked from network); 4 Aug 1999 20:37:41 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 4 Aug 1999 20:37:41 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA06206; Wed, 4 Aug 1999 13:37:28 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id NAA28497; Wed, 4 Aug 1999 13:37:28 -0700 To: law@cygnus.com Cc: John Wehle , egcs@egcs.cygnus.com Subject: Re: try_split lossage References: <11275.933793274@upchuck.cygnus.com> From: Jason Merrill Date: 04 Aug 1999 13:37:28 -0700 In-Reply-To: Jeffrey A Law's message of "Wed, 04 Aug 1999 13:01:14 -0600" Message-ID: Lines: 16 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Jeffrey A Law writes: >> There seems to be the potential to break EH if RTX_FRAME_RELATED_P is >> incorrect, however I'm somewhat naive when it comes to EH or dwarf2. > Ah. I wasn't aware of that usage. I think it's the only usage of RTX_FRAME_RELATED_P; it's certainly what I added it for. > But it's easy to handle -- if the insn we split was marked as frame > related, the resulting insns must also be frame related. Yup. Jason From gcc-return-8802-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 20:47:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1186 invoked by alias); 4 Aug 1999 20:47:04 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1056 invoked from network); 4 Aug 1999 20:46:33 -0000 Received: from margay.noc.ucla.edu (169.232.10.14) by egcs.cygnus.com with SMTP; 4 Aug 1999 20:46:33 -0000 Received: from localhost (imarkov@localhost) by margay.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id NAA23534; Wed, 4 Aug 1999 13:46:16 -0700 (PDT) Date: Wed, 4 Aug 1999 13:46:16 -0700 (PDT) From: IGOR LEONIDOVICH MARKOV To: egcs@egcs.cygnus.com cc: binaire@videotron.ca Subject: Illegal instruction (core dumped) on i586 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I had a very troublesome morning today, partly due to negligence of various people, apparently including egcs maintainers etc. First, I wanted to upgrade egcs to gcc-2.95 on my RedHat-6.0 system. You probably know that things come in "RPM"s for RedHat (a way to install stuff), but nothing was announced on teh RedHat mailing lists or egcs.cygnus.com So, I went to ftp://ftp.redhat.com/contrib and found gcc-2.95*rpm gcc-c++-2.95*rpm and the like. Downloaded those. Trying to install.. they conflict w egcs-1.1.2 (that came w Linux). Ok, removed egcs and egcs-c++ .. updated binutils to the latest... trying to compile a C++ hello world program, it can't find iostream.h .. ok, looked around, found libstdc++ RPMs (including devel). Installed them, but the previous version was needed by a bunch of programs including KDE and netscape, so I have two ATM. Now, I can compile cout << " hello" < (By the way, RPM install complained because it could not find user binaire... so was installing things as root) I suggest that egcs maintainers take care of RPMs for gcc-2.95 and (a) announce all necessary RPMs and the install sequence on their site, (b) dub the announcement through RedHat RPM lists thanks, Igor From gcc-return-8803-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 20:58:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3525 invoked by alias); 4 Aug 1999 20:58:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3508 invoked from network); 4 Aug 1999 20:58:38 -0000 Received: from margay.noc.ucla.edu (169.232.10.14) by egcs.cygnus.com with SMTP; 4 Aug 1999 20:58:38 -0000 Received: from localhost (imarkov@localhost) by margay.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id NAA25098; Wed, 4 Aug 1999 13:58:36 -0700 (PDT) Date: Wed, 4 Aug 1999 13:58:36 -0700 (PDT) From: IGOR LEONIDOVICH MARKOV To: egcs@egcs.cygnus.com cc: binaire@videotron.ca Subject: Re: Illegal instruction (core dumped) on i586 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Follow-up... I am able to compile and run a C hello world program, so this is likely to be an issue of stdc++ [imarkov@localhost ~]$ rpm -q libstdc++ libstdc++-2.9.0-12 libstdc++-2.95-2 [imarkov@localhost ~]$ quite likely, I should just force the upgrade of 2.9, but if this fails, many things may not work anymore, so I better wait for advice. Also, please cc: imarkov@cs.ucla.edu because I am not subscribed to the mailing list (reading it over the Web) Igor P.S. For some reason, posts from cs.ucla.edu are rejected by egcs.cygnus.com -- pretty obnoxious, I'd say. From gcc-return-8804-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 21:04:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4940 invoked by alias); 4 Aug 1999 21:04:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4924 invoked from network); 4 Aug 1999 21:04:42 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 4 Aug 1999 21:04:42 -0000 Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id RAA06416; Wed, 4 Aug 1999 17:04:39 -0400 (EDT) Received: from localhost by world.std.com (TheWorld/Spike-2.0) id AA00071; Wed, 4 Aug 1999 17:04:39 -0400 Date: Wed, 4 Aug 1999 17:04:39 -0400 From: Steven W Orr Reply-To: steveo@world.std.com To: IGOR LEONIDOVICH MARKOV Cc: egcs@egcs.cygnus.com, binaire@videotron.ca Subject: Re: Illegal instruction (core dumped) on i586 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Instead you should have gone to /contrib/libc6/SRPMS and fetched gcc-2.95-2.src.rpm and then rpm -i gcc-2.95-2.src.rpm cd /usr/src/redhat rpm -ba gcc.spec rpm -Uvh all the resulting i386.rpm files Then they would have been made for your machine. -- ----------Time flies like the wind. Fruit flies like a banana.---------------- --------Stranger things have happened but none stranger than this.------------- Steven W. Orr steveo@world.std.com ---------------"Listen to me! We are all individuals."------------------------- On Wed, 4 Aug 1999, IGOR LEONIDOVICH MARKOV wrote: => => Hi, => => I had a very troublesome morning today, partly due to negligence => of various people, apparently including egcs maintainers etc. First, I => wanted to upgrade egcs to gcc-2.95 on my RedHat-6.0 system. You probably => know that things come in "RPM"s for RedHat (a way to install stuff), but => nothing was announced on teh RedHat mailing lists or egcs.cygnus.com => So, I went to ftp://ftp.redhat.com/contrib and found gcc-2.95*rpm => gcc-c++-2.95*rpm and the like. Downloaded those. Trying to install.. => they conflict w egcs-1.1.2 (that came w Linux). Ok, removed egcs and => egcs-c++ .. updated binutils to the latest... trying to compile a => C++ hello world program, it can't find iostream.h .. ok, looked around, => found libstdc++ RPMs (including devel). Installed them, but the previous => version was needed by a bunch of programs including KDE and netscape, => so I have two ATM. => Now, I can compile cout << " hello" < but it does not run giving me "Illegal instruction (core dumped)" => => RPMs are signed by Hung Quan => (By the way, RPM install complained because it could not find => user binaire... so was installing things as root) => => I suggest that egcs maintainers take care of RPMs for gcc-2.95 => and (a) announce all necessary RPMs and the install sequence on => their site, (b) dub the announcement through RedHat RPM lists => => thanks, => Igor => => From gcc-return-8805-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 21:08:40 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6024 invoked by alias); 4 Aug 1999 21:08:39 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6002 invoked from network); 4 Aug 1999 21:08:36 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 4 Aug 1999 21:08:36 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id OAA02863; Wed, 4 Aug 1999 14:06:55 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id OAA02908; Wed, 4 Aug 1999 14:06:55 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id OAA13569; Wed, 4 Aug 1999 14:06:54 -0700 Message-Id: <199908042106.OAA13569@atrus.synopsys.com> Subject: Re: Illegal instruction (core dumped) on i586 To: imarkov@ucla.edu (IGOR LEONIDOVICH MARKOV) Date: Wed, 4 Aug 99 14:06:52 PDT Cc: egcs@egcs.cygnus.com, binaire@videotron.ca In-Reply-To: ; from "IGOR LEONIDOVICH MARKOV" at Aug 4, 99 1:46 pm X-Mailer: ELM [version 2.3 PL11] > > I had a very troublesome morning today, partly due to negligence > of various people, apparently including egcs maintainers etc. Nonsense. Your troubles are because of your own action and no one else's. > First, I > wanted to upgrade egcs to gcc-2.95 on my RedHat-6.0 system. You probably > know that things come in "RPM"s for RedHat (a way to install stuff), but > nothing was announced on teh RedHat mailing lists or egcs.cygnus.com That's because the RPMs you installed were not produced or approved by either the GCC (formerly EGCS) team nor by Red Hat. Some random person made them. That's why they are in the "contrib" directory. Anyone who installs such things does so entirely at his or her own risk. If the RPMs are defective, you can ask Red Hat to remove them if you like. > I suggest that egcs maintainers take care of RPMs for gcc-2.95 > and (a) announce all necessary RPMs and the install sequence on > their site, (b) dub the announcement through RedHat RPM lists Sorry, no. The GCC team produces a portable compiler for many operating systems. It will not do RPMs customized for Red Hat. That's Red Hat's job. Go bug them. The GCC team does not work for you, and is under no obligation to honor your demands. Throwing around offensive language like "negligence" only makes it less likely that anyone will help you. The GCC team provides a source distribution only. You can download it and compile it yourself if you wish. If you lack the expertise to do this, then wait for Red Hat to do it, or hire someone to do it for you. From gcc-return-8806-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 21:10:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6888 invoked by alias); 4 Aug 1999 21:10:34 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6873 invoked from network); 4 Aug 1999 21:10:32 -0000 Received: from smtp.ucla.edu (HELO serval.noc.ucla.edu) (169.232.10.57) by egcs.cygnus.com with SMTP; 4 Aug 1999 21:10:32 -0000 Received: from cs.ucla.edu (ts41-15.wla.ts.ucla.edu [164.67.23.60]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id OAA08813; Wed, 4 Aug 1999 14:10:28 -0700 (PDT) Message-ID: <37A8ACF5.E1B1C3F7@cs.ucla.edu> Date: Wed, 04 Aug 1999 14:13:25 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: steveo@world.std.com CC: egcs@egcs.cygnus.com, binaire@videotron.ca Subject: Re: Illegal instruction (core dumped) on i586 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Instead you should have gone to /contrib/libc6/SRPMS and fetched > gcc-2.95-2.src.rpm and then > rpm -i gcc-2.95-2.src.rpm > cd /usr/src/redhat > rpm -ba gcc.spec > rpm -Uvh all the resulting i386.rpm files > Then they would have been made for your machine. wait.. not so fast! I have a regular Pentium-150 (not an AMD or Cyrix clone), and downloaded RPMs from the i386 directory. I understand it's not a hacker thing to download binaries, but shouldn't that work? (and why do you want me to necessarily go through the source install) Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8807-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 21:13:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8207 invoked by alias); 4 Aug 1999 21:13:47 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8192 invoked from network); 4 Aug 1999 21:13:46 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 4 Aug 1999 21:13:46 -0000 Received: from cs.ucla.edu (ts41-15.wla.ts.ucla.edu [164.67.23.60]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id OAA10630; Wed, 4 Aug 1999 14:13:42 -0700 (PDT) Message-ID: <37A8ADB7.336B414A@cs.ucla.edu> Date: Wed, 04 Aug 1999 14:16:39 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Joe Buck CC: IGOR LEONIDOVICH MARKOV , egcs@egcs.cygnus.com, binaire@videotron.ca Subject: Re: Illegal instruction (core dumped) on i586 References: <199908042106.OAA13569@atrus.synopsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >> I had a very troublesome morning today, partly due to negligence >> of various people, apparently including egcs maintainers etc. > >Nonsense. Your troubles are because of your own action and no one else's. allright, I shouldn't have downloaded the RPMs... cool but don't you think that ensuring correct RPMs on egcs site is a prudent measure? (not necessarily making them... there are tons of people who RPMize new things as they come out) > If the RPMs are defective, you can ask Red Hat to remove them if you like. with pleasure... Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8808-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 21:17:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9990 invoked by alias); 4 Aug 1999 21:17:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9967 invoked from network); 4 Aug 1999 21:17:50 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 4 Aug 1999 21:17:50 -0000 Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id RAA08320; Wed, 4 Aug 1999 17:17:46 -0400 (EDT) Received: from localhost by world.std.com (TheWorld/Spike-2.0) id AA10495; Wed, 4 Aug 1999 17:17:45 -0400 Date: Wed, 4 Aug 1999 17:17:45 -0400 From: Steven W Orr Reply-To: steveo@world.std.com To: Igor Markov Cc: egcs@egcs.cygnus.com, binaire@videotron.ca Subject: Re: Illegal instruction (core dumped) on i586 In-Reply-To: <37A8ACF5.E1B1C3F7@cs.ucla.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sometimes it does work. The problem is that not all rpms are going to be compatible with all platforms. There might be differences between SUSE, RH, Debian, Caldera, etc such that the rpm might not work on a platform that it wasn't built on. In fact, if the rpm doesn't build from src then that's a good indication that there is a dependency that you are not yet aware of. Personally, I have my rpm customized so that it produces i686 instructions. If you got the rpm from redhat, then that's an indication that it was built for *some* sort of red hat system. If you're running RH6.0 then *usually* you will be able to run rpm's that are specifically built for 6.0 or are designated as 6.0 update rpms. BTW, The src install is required in order to do the build. The build produces the resulting rpms in /usr/src/redhat/RPMS. In this case they would all end up in the i386 subdirectory. -- ----------Time flies like the wind. Fruit flies like a banana.---------------- --------Stranger things have happened but none stranger than this.------------- Steven W. Orr steveo@world.std.com ---------------"Listen to me! We are all individuals."------------------------- On Wed, 4 Aug 1999, Igor Markov wrote: => =>> Instead you should have gone to /contrib/libc6/SRPMS and fetched =>> gcc-2.95-2.src.rpm and then =>> rpm -i gcc-2.95-2.src.rpm =>> cd /usr/src/redhat =>> rpm -ba gcc.spec =>> rpm -Uvh all the resulting i386.rpm files =>> Then they would have been made for your machine. => => wait.. not so fast! => I have a regular Pentium-150 (not an AMD or Cyrix clone), => and downloaded RPMs from the i386 directory. => => I understand it's not a hacker thing to download binaries, => but shouldn't that work? (and why do you want me to necessarily => go through the source install) => => Igor => From gcc-return-8809-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 21:35:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14678 invoked by alias); 4 Aug 1999 21:35:57 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14633 invoked from network); 4 Aug 1999 21:35:51 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 4 Aug 1999 21:35:51 -0000 Received: from cs.ucla.edu (ts41-15.wla.ts.ucla.edu [164.67.23.60]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id OAA22136; Wed, 4 Aug 1999 14:35:30 -0700 (PDT) Message-ID: <37A8B2D3.D4149D5D@cs.ucla.edu> Date: Wed, 04 Aug 1999 14:38:27 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: steveo@world.std.com, jbuck@synopsys.com, gcc@egcs.cygnus.com CC: binaire@videotron.ca Subject: Re: Illegal instruction (core dumped) on i586 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit somehow, I don't see the explanations making sense... Joe is essentially saying "use at your own risk"... that's not very helpful Steve says those RPMs were probably built on a platform different from mine --- but I can compile C just fine, it's C++ is giving me problems (all RPMs were compiled on the same machine by the same person, the same day). It seems to me, the issue is that of system libraries (libstdc++) and resp. dependencies -- something very easy to screw up and potentially fatal for many applications. It is certainly up to gcc maintainers to know what's new in libstc++-2.95 and what problems this may cause. That's the help I am trying to get here. Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8810-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 21:41:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15384 invoked by alias); 4 Aug 1999 21:41:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15316 invoked from network); 4 Aug 1999 21:41:09 -0000 Received: from host162.nashville.com (HELO rjlhome.sco.com) (207.65.231.162) by egcs.cygnus.com with SMTP; 4 Aug 1999 21:41:09 -0000 Received: (from robertl@localhost) by rjlhome.sco.com (8.8.8/SCO5) id QAA14163; Wed, 4 Aug 1999 16:40:17 -0500 (CDT) Date: Wed, 4 Aug 1999 16:40:17 -0500 From: Robert Lipe To: Igor Markov Cc: egcs@egcs.cygnus.com, binaire@videotron.ca Subject: Re: Illegal instruction (core dumped) on i586 Message-ID: <19990804164017.C13940@rjlhome.sco.com> References: <37A8ACF5.E1B1C3F7@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95us In-Reply-To: <37A8ACF5.E1B1C3F7@cs.ucla.edu>; from Igor Markov on Wed, Aug 04, 1999 at 02:13:25PM -0700 Igor Markov wrote: > I understand it's not a hacker thing to download binaries, > but shouldn't that work? (and why do you want me to necessarily > go through the source install) The product produced by the GCC (nee EGCS) group is a source release. The GCC group does not provide binary kits for any architecture. Other groups package these things up for specific environments with varying degrees of doc, testing, QA, and even quality. Problems with any binary distribution you're working should be directed to the party responsible for that distribution. Being rude with the GCC development team isn't likely to advance the state of your effort. This is the 1999 version "All the world is a VAX running BSD" syndrome.... From gcc-return-8811-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 21:46:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15982 invoked by alias); 4 Aug 1999 21:46:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15907 invoked from network); 4 Aug 1999 21:46:12 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 4 Aug 1999 21:46:12 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id PAA12042; Wed, 4 Aug 1999 15:38:01 -0600 X-Mailer: exmh version 2.0.2 To: IGOR LEONIDOVICH MARKOV cc: egcs@egcs.cygnus.com, binaire@videotron.ca Subject: Re: Illegal instruction (core dumped) on i586 Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 04 Aug 1999 13:58:36 PDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Aug 1999 15:38:01 -0600 Message-ID: <12039.933802681@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > P.S. For some reason, posts from cs.ucla.edu are rejected > by egcs.cygnus.com -- pretty obnoxious, I'd say. If it has an open relay, then it is not obnoxious at all and can be easily solved by having the folks at cs.ucla fix their spam-friendly mail system. jeff From gcc-return-8812-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 22:01:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20448 invoked by alias); 4 Aug 1999 22:01:07 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20431 invoked from network); 4 Aug 1999 22:01:02 -0000 Received: from tahallah.demon.co.uk (root@194.222.9.116) by egcs.cygnus.com with SMTP; 4 Aug 1999 22:01:02 -0000 Received: from localhost (alex@localhost [127.0.0.1]) by tahallah.demon.co.uk (8.9.3/8.9.0) with ESMTP id XAA18970; Wed, 4 Aug 1999 23:01:21 +0100 Date: Wed, 4 Aug 1999 23:01:21 +0100 (BST) From: Alex Buell X-Sender: alex@tahallah.demon.co.uk Reply-To: alex.buell@tahallah.demon.co.uk To: Igor Markov cc: gcc@egcs.cygnus.com Subject: Re: Illegal instruction (core dumped) on i586 In-Reply-To: <37A8B2D3.D4149D5D@cs.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 4 Aug 1999, Igor Markov wrote: > It is certainly up to gcc maintainers to know what's new You are using glibc are you? You may have been bitten by the binary incompatibility that exist between libraries built with different versions of gcc. Solution is to rebuild your glibc. I think. Cheers, Alex -- Legalise cannabis today! http://www.tahallah.demon.co.uk From gcc-return-8813-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 22:13:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23557 invoked by alias); 4 Aug 1999 22:13:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23542 invoked from network); 4 Aug 1999 22:13:50 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 4 Aug 1999 22:13:50 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id SAA09838; Wed, 4 Aug 1999 18:13:47 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id SAA21387; Wed, 4 Aug 1999 18:13:45 -0400 (EDT) Date: Wed, 4 Aug 1999 18:13:45 -0400 (EDT) From: John Wehle Message-Id: <199908042213.SAA21387@jwlab.FEITH.COM> To: imarkov@cs.ucla.edu Cc: gcc@egcs.cygnus.com Subject: Re: Illegal instruction (core dumped) on i586 Content-Type: text > somehow, I don't see the explanations making sense... > > Joe is essentially saying "use at your own risk"... > that's not very helpful It's hard to troubleshoot a product produced by a third party. The best people to supply support for that product is those people who made it. The product produced by the gcc maintainers is a source code release and I'm sure that they would be interest in problems building their product on RedHat. > It is certainly up to gcc maintainers to know what's new > in libstc++-2.95 and what problems this may cause. That's > the help I am trying to get here. I'm sure that they do know what's new in libstc++-2.95, unfortunately this isn't what you are asking about. You are asking about problems with a specific binary produced by a third party. It's true that the third party may have build the binary from gcc source code, however there's a lot of variables outside of gcc maintainers control which effect whether the binary in question will be useful for you. Presumably these variables are in the control of whoever built the binary. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-8814-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 22:17:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24771 invoked by alias); 4 Aug 1999 22:17:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24752 invoked from network); 4 Aug 1999 22:17:10 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 4 Aug 1999 22:17:10 -0000 Received: from cs.ucla.edu (ts41-15.wla.ts.ucla.edu [164.67.23.60]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id PAA15335; Wed, 4 Aug 1999 15:17:06 -0700 (PDT) Message-ID: <37A8BC93.18812C2@cs.ucla.edu> Date: Wed, 04 Aug 1999 15:20:03 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Robert Lipe CC: egcs@egcs.cygnus.com, binaire@videotron.ca Subject: Re: Illegal instruction (core dumped) on i586 References: <37A8ACF5.E1B1C3F7@cs.ucla.edu> <19990804164017.C13940@rjlhome.sco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > This is the 1999 version "All the world is a VAX running BSD" syndrome.... while this is totally unrelated to my questions, I think the comparison is somewhat warped. Linux is one of major GNU "customers" and egcs was trusted to become the official version of gcc by GNU. I would expect this assumes some responsibility. RPMs are used on most distros, RedHat is one of major distros (statistically most popular?). Also, the PC platform is clearly dominant. I doubt that BSD on VAX ever enjoyed such a popularity. I am very surprised that you are trying to marginalize a common platform and explicitely refuse to ensure consistent effort. Igor P.S. yes, I do understand that everyone is a volunteer and can dissapear forever in 5 mins, but I am not asking you to thank me for sending you bug reports. -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8815-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 22:19:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25704 invoked by alias); 4 Aug 1999 22:19:38 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25689 invoked from network); 4 Aug 1999 22:19:35 -0000 Received: from jl1.quim.ucm.es (root@147.96.5.12) by egcs.cygnus.com with SMTP; 4 Aug 1999 22:19:35 -0000 Received: (from ramon@localhost) by jl1.quim.ucm.es (8.9.3/8.9.3) id AAA01941 for gcc@gcc.gnu.org; Thu, 5 Aug 1999 00:22:30 +0200 Date: Thu, 5 Aug 1999 00:22:30 +0200 From: "Ram'on Garc'ia Fern'andez" To: gcc@gcc.gnu.org Subject: Some comments about quality of generanted code. Message-ID: <19990805002230.A1934@jl1.quim.ucm.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us Hello, I have just tested the new GCC 2.95 on a Pentium II/Linux machine and I have some comments to make. 1) Stack alignment code GCC generates lots of redundant code to access the stack, for example: main: .LFB1: pushl %ebp .LCFI0: movl %esp,%ebp .LCFI1: subl $116,%esp .LCFI2: pushl %ebx .LCFI3: addl $-12,%esp pushl $8 .LCFI4: call __builtin_new movl %eax,%ebx movb $1,-97(%ebp) .LEHB529: addl $16,%esp addl $-8,%esp See the last two instructions. They could be replaced by one. The problem is related with the attempts to keep the stack aligned. Compiling with -mpreferred-stack-boundary=2 removes the problem. The amount of code added by stack alignment is very large. The size of the code that I tested changed from 471 bytes to 414 when enabling this option. I believe that stack alignment is beneficial for floating point. I am not sure if this high alignment should be done by default. Anyway, if done, it would be much better to do it in such way that these redundant calculations can be simplified. 2) Exception handling Other feature that stroke my attention is the amount of code added by exception handling. The size of the main function above changed from 116 bytes to 471 bytes when enabling exception handling (this does included the code only; it does not include the tables). A bit large, isn't it? Look at the generated code yourself. I tested with -fnew-abi, but did not see any change. Just some change in the manged name of std::terminate. All the code exactly the same. 3) PIC Another comment is abut the code generated using -fPIC. This flag reserves a register for accessing global variables through the GOT table, right? This is not necessary for global functions, thanks to the relative call instruction. However, at present GCC allocates this register always, even if there are no global variables in a function, which is a very frecuent situation in well structured code. I believe that the correct way of supporting PIC code would be to add an expression that calculates the GOT position at the top of the function, and then use that expression. So if it is not used, because there are no global variables, it could be simply removed. Otherwise it could be calculated in the most optimal way, for example, if there is one global variable only, the register with the GOT address would be locked only as long as it is needed for calculating that variable, rather that along all the function. In my test code std::cout is the only global variable, but the register %ebx is locked along all the function. I am attaching here the code that I used for all the comments above as well as the assembly output (compiled without PIC). 4) New IA32 backend A final comment regarding the new IA32 backend recently donated by Cygnus solutions. I have tested it and it is really an improvement. Testing some Fortran codes that we use for benchmarking, the new G77 compiler with this backend performs exactly like the Porland group compiler. I had no problems running it with -O3 -ffast-math -march=pentiumpro -fomit-frame-pointer. The code gived correct results. By contrast, the standard G77 from GCC-2.95 performs about 15 - 20 % slower. Since testing the new backend should not be very complicated (it is just for one architecture) it would be very good if there is a release of GCC with that new backend. 15 % of performance makes a lot of diffence, it is like changing from a Pentium 400 MHz to a Pentium 460 MHz. It would be very good to release a version of GCC with the new backend before GCC 3.0. The Porland compiler is becoming very popular in the scientific comunity. Therefore an early relase of GCC with the new backend would encourage more use of free software. Ramon From gcc-return-8816-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 22:22:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26614 invoked by alias); 4 Aug 1999 22:22:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26599 invoked from network); 4 Aug 1999 22:22:12 -0000 Received: from jl1.quim.ucm.es (root@147.96.5.12) by egcs.cygnus.com with SMTP; 4 Aug 1999 22:22:12 -0000 Received: (from ramon@localhost) by jl1.quim.ucm.es (8.9.3/8.9.3) id AAA01953 for gcc@gcc.gnu.org; Thu, 5 Aug 1999 00:25:09 +0200 Date: Thu, 5 Aug 1999 00:25:09 +0200 From: "Ram'on Garc'ia Fern'andez" To: gcc@gcc.gnu.org Subject: Some comments about the quality of generated code. Message-ID: <19990805002509.A1947@jl1.quim.ucm.es> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=2fHTh5uZTiUOsy+g X-Mailer: Mutt 0.95.4us --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii In my last e-mail I forgot to send the attachments that I mentioned. sorry. --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Description: Source code of test program Content-Disposition: attachment; filename="gc.cpp" #include using namespace std; // A smart pointer implementation // template class ref_counted { public: ref_counted() : obj(), ref_count(1) {} template ref_counted(Arg1 a): obj(a), ref_count(1) {} template ref_counted(Arg1 a1, Arg2 a2): obj(a1, a2), ref_count(1) {} template ref_counted(Arg1 a1, Arg2 a2, Arg3 a3): obj(a1, a2, a3), ref_count(1) {} template ref_counted(Arg1 a1, Arg2 a2, Arg3 a3, Arg4 a4): obj(a1, a2, a3, a4), ref_count(1) {} void ref() {ref_count++;} // The caller sould delete this object it is no longer used bool unref() {ref_count--; return ref_count == 0;} private: T obj; int ref_count; }; template class smart_ptr { public: smart_ptr(): ptr(new ref_counted()) {} smart_ptr(smart_ptr& g): ptr(g.ptr) { g.ptr->ref(); } template smart_ptr(Arg1 a1): ptr(new ref_counted(a1)) {} template smart_ptr(Arg1 a1, Arg2 a2): ptr(new ref_counted(a1, a2)) {} template smart_ptr(Arg1 a1, Arg2 a2, Arg3 a3): ptr(new ref_counted(a1, a2, a3)) {} template smart_ptr(Arg1 a1, Arg2 a2, Arg3 a3, Arg4 a4): ptr(new ref_counted(a1, a2, a3, a4)) {} ~smart_ptr() { if (ptr->unref()) delete ptr; } smart_ptr& operator=(smart_ptr& g) { if (ptr->unref()) delete ptr; ptr = g->ptr; return this; } T* operator->() { return &ptr->obj; } private: ref_counted* ptr; }; class X { public: X() { cout << "Constructing X\n"; } ~X() { cout << "Destructiong X\n"; } }; int main() { typedef smart_ptr X_ptr; X_ptr x; X_ptr y = x; X_ptr z = x; } --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Description: Assembly output. Used -fnew-abi Content-Disposition: attachment; filename="main.gnu.newabi.s" .file "main.cpp" .version "01.01" gcc2_compiled.: .globl __throw .section .rodata .LC0: .string "Constructing X\n" .LC1: .string "Destructiong X\n" .text .align 4 .globl main .type main,@function main: .LFB1: pushl %ebp .LCFI0: movl %esp,%ebp .LCFI1: subl $116,%esp .LCFI2: pushl %ebx .LCFI3: addl $-12,%esp pushl $8 .LCFI4: call __builtin_new movl %eax,%ebx movb $1,-97(%ebp) .LEHB529: addl $16,%esp addl $-8,%esp pushl $.LC0 pushl $cout call __ls__7ostreamPCc movl $1,4(%ebx) addl $16,%esp movb $0,-97(%ebp) movl %ebx,-32(%ebp) .LEHE529: jmp .L545 .p2align 4,,7 .L546: .LCFI5: call __throw .p2align 4,,7 .L545: cmpb $0,-97(%ebp) je .L550 addl $-12,%esp pushl %ebx .LCFI6: call __builtin_delete addl $16,%esp jmp .L550 .LEHB552: .p2align 4,,7 .L529: cmpb $0,-97(%ebp) je .L546 addl $-12,%esp pushl %ebx call __builtin_delete addl $16,%esp jmp .L546 .LEHE552: .p2align 4,,7 .L552: .LCFI7: call terminate__3stdv .p2align 4,,7 .L550: .LEHB557: movl -32(%ebp),%ebx movl %ebx,-64(%ebp) movl 4(%ebx),%eax .LEHB566: movl %ebx,-96(%ebp) leal 1(%eax),%edx movl %edx,4(%ebx) cmpl $-1,%eax jne .L590 testl %ebx,%ebx je .L590 addl $-8,%esp pushl $.LC1 pushl $cout .LCFI8: call __ls__7ostreamPCc addl $16,%esp addl $-12,%esp pushl %ebx call __builtin_delete addl $16,%esp .LEHE566: jmp .L590 .p2align 4,,7 .L567: .LCFI9: call __throw .p2align 4,,7 .L590: movl -64(%ebp),%ebx movl 4(%ebx),%eax leal -1(%eax),%edx movl %edx,4(%ebx) cmpl $1,%eax jne .L607 testl %ebx,%ebx je .L607 addl $-8,%esp pushl $.LC1 pushl $cout .LCFI10: call __ls__7ostreamPCc addl $16,%esp addl $-12,%esp pushl %ebx call __builtin_delete addl $16,%esp .LEHE557: jmp .L607 .p2align 4,,7 .L558: .LCFI11: call __throw .p2align 4,,7 .L607: movl -32(%ebp),%ebx movl 4(%ebx),%eax leal -1(%eax),%edx movl %edx,4(%ebx) cmpl $1,%eax jne .L623 testl %ebx,%ebx je .L623 addl $-8,%esp pushl $.LC1 pushl $cout .LCFI12: call __ls__7ostreamPCc addl $16,%esp addl $-12,%esp pushl %ebx call __builtin_delete .L623: xorl %eax,%eax jmp .L676 .LEHB673: .p2align 4,,7 .L566: movl -64(%ebp),%ebx movl 4(%ebx),%eax leal -1(%eax),%edx movl %edx,4(%ebx) cmpl $1,%eax jne .L567 testl %ebx,%ebx je .L567 addl $-8,%esp pushl $.LC1 pushl $cout call __ls__7ostreamPCc addl $16,%esp addl $-12,%esp pushl %ebx call __builtin_delete addl $16,%esp jmp .L567 .p2align 4,,7 .L557: movl -32(%ebp),%ebx movl 4(%ebx),%eax leal -1(%eax),%edx movl %edx,4(%ebx) cmpl $1,%eax jne .L558 testl %ebx,%ebx je .L558 addl $-8,%esp pushl $.LC1 pushl $cout call __ls__7ostreamPCc addl $16,%esp addl $-12,%esp pushl %ebx call __builtin_delete addl $16,%esp jmp .L558 .LEHE673: .p2align 4,,7 .L673: .LCFI13: call terminate__3stdv .p2align 4,,7 .L676: movl -120(%ebp),%ebx movl %ebp,%esp popl %ebp ret .LFE1: .Lfe1: .size main,.Lfe1-main .section .gcc_except_table,"aw",@progbits .align 4 __EXCEPTION_TABLE__: .long .LEHB529 .long .LEHE529 .long .L529 .long .LEHB552 .long .LEHE552 .long .L552 .long .LEHB557 .long .LEHE557 .long .L557 .long .LEHB566 .long .LEHE566 .long .L566 .long .LEHB673 .long .LEHE673 .long .L673 .LRTH1: .long -1 .long -1 .section .eh_frame,"aw",@progbits __FRAME_BEGIN__: .4byte .LLCIE1 .LSCIE1: .4byte 0x0 .byte 0x1 .string "eh" .4byte __EXCEPTION_TABLE__ .byte 0x1 .byte 0x7c .byte 0x8 .byte 0xc .byte 0x4 .byte 0x4 .byte 0x88 .byte 0x1 .align 4 .LECIE1: .set .LLCIE1,.LECIE1-.LSCIE1 .4byte .LLFDE1 .LSFDE1: .4byte .LSFDE1-__FRAME_BEGIN__ .4byte .LFB1 .4byte .LFE1-.LFB1 .byte 0x4 .4byte .LCFI0-.LFB1 .byte 0xe .byte 0x8 .byte 0x85 .byte 0x2 .byte 0x4 .4byte .LCFI1-.LCFI0 .byte 0xd .byte 0x5 .byte 0x4 .4byte .LCFI3-.LCFI1 .byte 0x83 .byte 0x20 .byte 0x4 .4byte .LCFI4-.LCFI3 .byte 0x2e .byte 0x10 .byte 0x4 .4byte .LCFI5-.LCFI4 .byte 0x2e .byte 0x0 .byte 0x4 .4byte .LCFI6-.LCFI5 .byte 0x2e .byte 0x10 .byte 0x4 .4byte .LCFI7-.LCFI6 .byte 0x2e .byte 0x0 .byte 0x4 .4byte .LCFI8-.LCFI7 .byte 0x2e .byte 0x10 .byte 0x4 .4byte .LCFI9-.LCFI8 .byte 0x2e .byte 0x0 .byte 0x4 .4byte .LCFI10-.LCFI9 .byte 0x2e .byte 0x10 .byte 0x4 .4byte .LCFI11-.LCFI10 .byte 0x2e .byte 0x0 .byte 0x4 .4byte .LCFI12-.LCFI11 .byte 0x2e .byte 0x10 .byte 0x4 .4byte .LCFI13-.LCFI12 .byte 0x2e .byte 0x0 .align 4 .LEFDE1: .set .LLFDE1,.LEFDE1-.LSFDE1 .ident "GCC: (GNU) 2.95 19990728 (release)" --2fHTh5uZTiUOsy+g-- From gcc-return-8817-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 22:22:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26909 invoked by alias); 4 Aug 1999 22:22:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26862 invoked from network); 4 Aug 1999 22:22:43 -0000 Received: from smtp.ucla.edu (HELO serval.noc.ucla.edu) (169.232.10.57) by egcs.cygnus.com with SMTP; 4 Aug 1999 22:22:43 -0000 Received: from cs.ucla.edu (ts41-15.wla.ts.ucla.edu [164.67.23.60]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id PAA18160; Wed, 4 Aug 1999 15:22:38 -0700 (PDT) Message-ID: <37A8BDE0.3CAFE6DE@cs.ucla.edu> Date: Wed, 04 Aug 1999 15:25:36 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Wehle CC: gcc@egcs.cygnus.com Subject: Re: Illegal instruction (core dumped) on i586 References: <199908042213.SAA21387@jwlab.FEITH.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, thanks... what you are saying makes sense, but my main suggestion was that egcs maintainers consider ensuring the availability of good RPMs. This may include contacting someone who can pack RPMs, or learning the RPM tricks or... talking to RedHat, whatever. Please do not consider this as "making binaries for every trashy system", but rather "ensuring the utility to major customers". I don't suppose many windows applications depend on gcc and libs, neither on Solaris or HP-UX. gcc is the default compiler on Linux. Things are very difft here. Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8818-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 22:41:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30044 invoked by alias); 4 Aug 1999 22:41:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30019 invoked from network); 4 Aug 1999 22:40:45 -0000 Received: from gnat6.owo.com (HELO origin.ea.com) (208.12.170.6) by egcs.cygnus.com with SMTP; 4 Aug 1999 22:40:45 -0000 Received: from forest.origin.ea.com (molach.origin.ea.com [159.153.98.2]) by origin.ea.com (8.8.8/8.8.8PJ) with ESMTP id RAA28127; Wed, 4 Aug 1999 17:56:50 -0500 (CDT) Received: by molach.origin.ea.com with Internet Mail Service (5.5.2448.0) id ; Wed, 4 Aug 1999 17:32:58 -0500 Message-ID: <11A17AA2B9EAD111BCEA00A0C9B4179301BA88CB@molach.origin.ea.com> From: "Beardsley, Jason" To: "'Igor Markov'" Cc: gcc@egcs.cygnus.com Subject: RE: Illegal instruction (core dumped) on i586 Date: Wed, 4 Aug 1999 17:32:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" IMHO, implying that the GCC group should take any kind of responsibility for RPMs uploaded to RedHat's contrib directory is utterly ridiculous. I can't imagine you seriously mean that. If the packages don't work, then complain to the people who built them. If you can't wait for RedHat to issue an official upgrade to GCC 2.95, then may I suggest building it from source? Jason Beardsley -----Original Message----- From: Igor Markov [mailto:imarkov@cs.ucla.edu] Sent: Wednesday, August 04, 1999 5:26 PM To: John Wehle Cc: gcc@egcs.cygnus.com Subject: Re: Illegal instruction (core dumped) on i586 John, thanks... what you are saying makes sense, but my main suggestion was that egcs maintainers consider ensuring the availability of good RPMs. This may include contacting someone who can pack RPMs, or learning the RPM tricks or... talking to RedHat, whatever. Please do not consider this as "making binaries for every trashy system", but rather "ensuring the utility to major customers". I don't suppose many windows applications depend on gcc and libs, neither on Solaris or HP-UX. gcc is the default compiler on Linux. Things are very difft here. Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8819-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 22:49:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31345 invoked by alias); 4 Aug 1999 22:49:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31278 invoked from network); 4 Aug 1999 22:49:00 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 4 Aug 1999 22:49:00 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id PAA12369; Wed, 4 Aug 1999 15:48:46 -0700 (PDT) Received: by kankakee.wrs.com (SMI-8.6/SMI-SVR4) id PAA24392; Wed, 4 Aug 1999 15:48:46 -0700 Date: Wed, 4 Aug 1999 15:48:46 -0700 From: mrs@wrs.com (Mike Stump) Message-Id: <199908042248.PAA24392@kankakee.wrs.com> To: gcc@gcc.gnu.org, ramon@jl1.quim.ucm.es Subject: Re: Some comments about quality of generanted code. > Date: Thu, 5 Aug 1999 00:22:30 +0200 > From: "Ram'on Garc'ia Fern'andez" > 4) New IA32 backend > A final comment regarding the new IA32 backend recently donated by > Cygnus solutions. I have tested it and it is really an improvement. > By contrast, the standard G77 from GCC-2.95 performs about 15 - 20 % > slower. Since testing the new backend should not be very > complicated (it is just for one architecture) it would be very good > if there is a release of GCC with that new backend. Thanks for all your comments about the new IA32 backend. It helps to know that people are kicking it around, putting some mileage on it and testing it out. There is quite a lot of hard work in there, and I for one would love to see it tested and any remaining issues ironed out and it put into gcc. As to timing, well, in the end that is up to the gcc team to determine. While I like the work a whole lot, I don't think gcc 3.0 should be released around it. And improvements in one port typically are not enough to warrant an otherwise unplanned gcc release. Maybe gcc will have the work integrated and tested and a 3.0 release issued soon enough to please people that want to see this work. For those that can't wait, there is cvs. Thanks for the testing and the feedback. From gcc-return-8820-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 22:56:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 895 invoked by alias); 4 Aug 1999 22:56:34 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 879 invoked from network); 4 Aug 1999 22:56:26 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 4 Aug 1999 22:56:26 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id SAA10384; Wed, 4 Aug 1999 18:56:23 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id SAA21588; Wed, 4 Aug 1999 18:56:22 -0400 (EDT) Date: Wed, 4 Aug 1999 18:56:22 -0400 (EDT) From: John Wehle Message-Id: <199908042256.SAA21588@jwlab.FEITH.COM> To: imarkov@cs.ucla.edu CC: gcc@egcs.cygnus.com Subject: Re: Illegal instruction (core dumped) on i586 Content-Type: text > thanks... what you are saying makes sense, but my > main suggestion was that egcs maintainers consider > ensuring the availability of good RPMs. This may > include contacting someone who can pack RPMs, or > learning the RPM tricks or... talking to RedHat, > whatever. Please do not consider this as "making > binaries for every trashy system", but rather > "ensuring the utility to major customers". A very understandable suggestion clearly stated, unfortunately the wording on early emails seemed a little harsh and not as clear. 1) The RPMs tend to quickly get very platform specific which means that it's a very big matrix to support. The gcc maintainers are concerned that good RPMs are available, however they expect the bulk of the responsibility for this to be handled by each OS vendor since the OS vendor knows best how to configure the software for their system. 2) Since the gcc maintainers release a source code product which anyone can use and / or distribute (as long as the copyright is respected), it's difficult for them to act as police and prevent RPMs which are not appropriate for some people to be placed on ftp sites. Keep in mind that they are somewhat understaffed and overworked as it is ... and quite frankly it's not their job. I expect that RedHat will at some point release a RPM which will work for you. Unfortunately it sounds like what you grabbed wasn't released by RedHat for your platform. If it's urgent that you have the new release *now* then you can: 1) Try random RPMs and contact whoever built the RPM for help. 2) Try building gcc 2.95 from the original source code. If you run into problems then follow the instructions for reporting a bug and someone probably will try to help out. 3) Find / hire someone to help you in this endeavor. Sorry I can't be of more help (my only RedHat development system at the moment is 5.2 and it's awaiting a new motherboard). -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-8821-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 22:57:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1339 invoked by alias); 4 Aug 1999 22:57:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1249 invoked from network); 4 Aug 1999 22:57:30 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 4 Aug 1999 22:57:30 -0000 Received: from cs.ucla.edu (ts41-15.wla.ts.ucla.edu [164.67.23.60]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id PAA06051; Wed, 4 Aug 1999 15:57:26 -0700 (PDT) Message-ID: <37A8C607.1F298061@cs.ucla.edu> Date: Wed, 04 Aug 1999 16:00:23 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 CC: gcc@egcs.cygnus.com Subject: FYI References: <11A17AA2B9EAD111BCEA00A0C9B4179301BA88CB@molach.origin.ea.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I mailed to Michael Johnson of RedHat sometime ago re: the RPMs for gcc and also contacted (many hrs ago) a guy who builds new RPMs daily and announces them on a redhat mailing list. My point was that it would have been a prudent measure for the egcs group and cygnus support to establish such contacts earlier... apparently you are of a difft opinion; oh well... It's probably even less effort than typing replies to my emails ;) Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8822-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 23:27:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4977 invoked by alias); 4 Aug 1999 23:27:04 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4962 invoked from network); 4 Aug 1999 23:27:01 -0000 Received: from beezer.med.miami.edu (root@129.171.143.105) by egcs.cygnus.com with SMTP; 4 Aug 1999 23:27:01 -0000 Received: from beezer.med.miami.edu (chris@beezer.med.miami.edu [129.171.143.105]) by beezer.med.miami.edu (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA11216; Wed, 4 Aug 1999 19:26:45 -0400 Date: Wed, 4 Aug 1999 19:26:44 -0400 (EDT) From: Christopher C Chimelis X-Sender: chris@beezer.med.miami.edu To: Igor Markov cc: gcc@egcs.cygnus.com Subject: Re: FYI In-Reply-To: <37A8C607.1F298061@cs.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 4 Aug 1999, Igor Markov wrote: > > I mailed to Michael Johnson of RedHat sometime ago re: the RPMs > for gcc and also contacted (many hrs ago) a guy who builds new RPMs > daily and announces them on a redhat mailing list. > > My point was that it would have been a prudent measure for the > egcs group and cygnus support to establish such contacts earlier... > apparently you are of a difft opinion; oh well... > > It's probably even less effort than typing replies to my emails ;) While I'm not a member of the egcs/gcc group, I can understand both sides of this issue. Igor, what they're trying to convey is that, because of the sheer number of configurations and platforms supported by GCC, it would be nearly impossible to keep a list of responsible parties for each (partially because of time and partially because of turnover at each respective company/organisation). I can definitely understand your point about ensuring that quality binary packages are generated from the gcc group's work, but at the same time, they have enough work to do without having to call and/or write everyone on a list regarding their releases. On another note, to claim that Linux (and more specifically ix86 RedHat Linux) is the dominant OS obviously is not only irrelevant, but is also incorrect. My workplace, for example, uses both Alpha and i386 machines running Debian Linux. To me, Debian is the most obvious and dominant OS of choice, but install-base does not necessarily dictate what the gcc group should and shouldn't look after. There are certainly MANY different people using a variety of platforms that probably use and rely on GCC far more than either of us do. Does the fact that they use Solaris make them any further down the list just because Solaris isn't as widely installed as RedHat Linux? Lastly, consider this: being a Debian developer who's thoroughly familiar with RedHat's distribution, I've found that all RH releases rely solely on the compiler distributed with them and do NOT *require* that a newer version be installed. Basically, if you want to ensure the quality of the package, wait for RedHat's next release (which will most likely include gcc 2.95). On the other hand, using third-party builds of packages is always risky. I've watched RedHat's contrib directory over the years and have been frightened at times at how poor the quality of some of the packages there really is. A solution: write to one of the RedHat lists and ask if anyone has a working gcc 2.95 RPM set finished and working. If you get numerous responces from people (all using the same set on configurations similar to yours), then try the ones that they use and you will most likely get better results than you have thusfar. Good luck... C PS. I recently built the Debian .deb binary packages for Debian Alpha, so let me assure you that there are MANY MANY variables that have to be considered by the packager. ALOT can go wrong (and in this case probably has). From gcc-return-8823-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 23:44:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7290 invoked by alias); 4 Aug 1999 23:44:30 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7131 invoked from network); 4 Aug 1999 23:44:02 -0000 Received: from oscar.peakss.com (HELO mail.peakss.com) (207.174.113.161) by egcs.cygnus.com with SMTP; 4 Aug 1999 23:44:02 -0000 Received: from [172.28.0.200] (ignatz.pc.peakss.com [172.28.0.200]) by mail.peakss.com (8.8.7/8.8.8) with ESMTP id RAA13526 for ; Wed, 4 Aug 1999 17:43:49 -0600 Mime-Version: 1.0 X-Sender: kds@mail.peakss.com (Unverified) Message-Id: Date: Wed, 4 Aug 1999 17:43:49 -0600 To: gcc@gcc.gnu.org From: Kevin Stephens Subject: gcc-2.95 on i386-pc-sysv4.2uw2.1.3 success Content-Type: text/plain; charset="us-ascii" ; format="flowed" gcc-2.95 built successfully on i386-pc-sysv4.2uw2.1.3. Kevin Stephens Peak Software Solutions kds@peakss.com From gcc-return-8824-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 23:47:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8057 invoked by alias); 4 Aug 1999 23:47:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7956 invoked from network); 4 Aug 1999 23:47:23 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 4 Aug 1999 23:47:23 -0000 Received: from cs.ucla.edu (ts41-15.wla.ts.ucla.edu [164.67.23.60]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id QAA00913; Wed, 4 Aug 1999 16:47:09 -0700 (PDT) Message-ID: <37A8D1B0.929B7B53@cs.ucla.edu> Date: Wed, 04 Aug 1999 16:50:08 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Christopher C Chimelis CC: gcc@egcs.cygnus.com Subject: Re: FYI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hmmm... I have been working with SunPro CC as a C++ compiler for years because g++ could not compile C++ code that I wrote. MSVC++ is another problem our lab supports. Now, with the new release of gcc, we planned to maintain the code with g++ in addition to those two. I spent half a day overall and discovered a strange but apparent ignorance of final users that the gcc team has. We will have to wait until the smoke clears and personal ambitions settle down. Finally, Chris, I appreciate your efforts to interpret emails to the two parties, but I can only stand by what I wrote ---- I am pretty sure that PCs dominate general purpose computers, and that, independently, RedHat is dominating Linux installations -- I saw this published ;-) (I think you slightly misquoted me on this) Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8825-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 23:48:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8151 invoked by alias); 4 Aug 1999 23:48:04 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8008 invoked from network); 4 Aug 1999 23:47:37 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 4 Aug 1999 23:47:37 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id QAA15584; Wed, 4 Aug 1999 16:46:29 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id QAA05932; Wed, 4 Aug 1999 16:46:28 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id QAA18905; Wed, 4 Aug 1999 16:46:27 -0700 Message-Id: <199908042346.QAA18905@atrus.synopsys.com> Subject: Re: Illegal instruction (core dumped) on i586 To: imarkov@cs.ucla.edu (Igor Markov) Date: Wed, 4 Aug 99 16:46:27 PDT Cc: robertlipe@usa.net, egcs@egcs.cygnus.com, binaire@videotron.ca In-Reply-To: <37A8BC93.18812C2@cs.ucla.edu>; from "Igor Markov" at Aug 4, 99 3:20 pm X-Mailer: ELM [version 2.3 PL11] > Linux is one of major GNU "customers" and egcs was trusted to become > the official version of gcc by GNU. I would expect this assumes some > responsibility. Yes. GCC 2.95 was thoroughly tested on Red Hat 6.0. > I am very surprised that you are trying to marginalize a common > platform and explicitely refuse to ensure consistent effort. Nonsense. Package management is important, but is not the job of the GCC team. It is the job of those who put together distributions. Complain to them. The GCC team will not provide binary distributions for any platform, period (though some member of the team might, on his own, do so). Let's say that we did put out an RPM and called it "official". If we did, we'd be stepping on Red Hat's turf. It's up to them to produce a *set* of RPMs that are consistent with each other, decide on version numbers, etc. > P.S. yes, I do understand that everyone is a volunteer and can > dissapear forever in 5 mins, but I am not asking you to thank me > for sending you bug reports. You are sending bug reports to the wrong place. Send them to the person who made the RPMs. And you also need to learn to communicate more politely. With all of the stresses of getting this release out and dealing with last-minute FSF concerns, people are stressed out. We really don't need to hear insults from a whiner who messed up his system by his own actions and seeks to blame others. From gcc-return-8826-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 04 23:55:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11174 invoked by alias); 4 Aug 1999 23:55:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11157 invoked from network); 4 Aug 1999 23:55:07 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 4 Aug 1999 23:55:07 -0000 Received: from cs.ucla.edu (ts41-15.wla.ts.ucla.edu [164.67.23.60]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id QAA05072; Wed, 4 Aug 1999 16:54:57 -0700 (PDT) Message-ID: <37A8D384.C2E697FE@cs.ucla.edu> Date: Wed, 04 Aug 1999 16:57:56 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Joe Buck CC: robertlipe@usa.net, egcs@egcs.cygnus.com, binaire@videotron.ca Subject: Re: Illegal instruction (core dumped) on i586 References: <199908042346.QAA18905@atrus.synopsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ok... last email on this 1. Joe, the author of buggy RPMs is on the cc: of all the messages, including yours. > Package management is important, but is not the job of the GCC team. 2. You can contact people who can do this Saying that the matrix of distributions is too big makes little sense. I'd expect at most a few dozens configurations. Keeping a mailing list for people who can ensure that binaries are available isn't hard. Finally, if you guys are stressed out and don't have time, why don't you just put a disclaimer on egcs site ---- "will be done later", so that I don't really plan on using gcc (aftering getting burnt by expecting a release in the first half of July). Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8827-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 00:01:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12599 invoked by alias); 5 Aug 1999 00:01:19 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12527 invoked from network); 5 Aug 1999 00:01:11 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 5 Aug 1999 00:01:11 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id RAA16482; Wed, 4 Aug 1999 17:00:09 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id RAA09608; Wed, 4 Aug 1999 17:00:06 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id RAA19356; Wed, 4 Aug 1999 17:00:05 -0700 Message-Id: <199908050000.RAA19356@atrus.synopsys.com> Subject: Re: Illegal instruction (core dumped) on i586 To: imarkov@cs.ucla.edu (Igor Markov) Date: Wed, 4 Aug 99 17:00:04 PDT Cc: steveo@world.std.com, jbuck@synopsys.com, gcc@egcs.cygnus.com, binaire@videotron.ca In-Reply-To: <37A8B2D3.D4149D5D@cs.ucla.edu>; from "Igor Markov" at Aug 4, 99 2:38 pm X-Mailer: ELM [version 2.3 PL11] > somehow, I don't see the explanations making sense... > > Joe is essentially saying "use at your own risk"... > that's not very helpful OK, I'll help you. I'll tell you exactly how to get gcc-2.95 running on your system. These instructions assume that you have the development tools installed (e.g. you have gcc, make and friends). 1. Download the tar file. You will have a big file named gcc-2.95.tar.gz. 2. Unpack it. Type tar zxf gcc-2.95.tar.gz 3. Type cd gcc-2.95 4. Type ./configure 5. Type make bootstrap-lean 6. (As a user that has permission to write /usr/local): type make install You now have gcc-2.95 in /usr/local/bin/gcc . Note that this method will give you a statically linked libstdc++.a, so your binaries will be large. But since you don't appear to be particularly competent, this will be the safest method to keep you from hosing your system (breaking existing C++ executables by adding an incompatible libstdc++). If you do this and find that you have problems, read the FAQ. From gcc-return-8828-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 00:05:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13917 invoked by alias); 5 Aug 1999 00:05:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13898 invoked from network); 5 Aug 1999 00:05:46 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 5 Aug 1999 00:05:46 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id SAA12540; Wed, 4 Aug 1999 18:01:54 -0600 X-Mailer: exmh version 2.0.2 To: Igor Markov cc: Joe Buck , robertlipe@usa.net, egcs@egcs.cygnus.com, binaire@videotron.ca Subject: Re: Illegal instruction (core dumped) on i586 Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 04 Aug 1999 16:57:56 PDT. <37A8D384.C2E697FE@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Aug 1999 18:01:54 -0600 Message-ID: <12537.933811314@upchuck.cygnus.com> From: Jeffrey A Law In message <37A8D384.C2E697FE@cs.ucla.edu>you write: > Saying that the matrix of distributions is too big makes little sense. > I'd expect at most a few dozens configurations. Keeping a mailing list > for people who can ensure that binaries are available isn't hard. It is. As the person in charge of release logistics, this is a huge project and not one we are going to take on. Sorry, but that's life. Stop whining. If you don't like the RPMs complain to the people who made them, but do not cc us on it, this is not our problem. jeff From gcc-return-8829-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 00:29:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19223 invoked by alias); 5 Aug 1999 00:29:12 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19160 invoked from network); 5 Aug 1999 00:28:58 -0000 Received: from beezer.med.miami.edu (root@129.171.143.105) by egcs.cygnus.com with SMTP; 5 Aug 1999 00:28:58 -0000 Received: from beezer.med.miami.edu (chris@beezer.med.miami.edu [129.171.143.105]) by beezer.med.miami.edu (8.9.3/8.9.3/Debian/GNU) with SMTP id UAA14010; Wed, 4 Aug 1999 20:28:52 -0400 Date: Wed, 4 Aug 1999 20:28:51 -0400 (EDT) From: Christopher C Chimelis X-Sender: chris@beezer.med.miami.edu To: Igor Markov cc: gcc@egcs.cygnus.com Subject: Re: FYI In-Reply-To: <37A8D1B0.929B7B53@cs.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 4 Aug 1999, Igor Markov wrote: > hmmm... I have been working with SunPro CC as a C++ compiler > for years because g++ could not compile C++ code that I wrote. > MSVC++ is another problem our lab supports. Hehehe..yes, MSVC++ can be a difficult animal itself :-) > Now, with the new release of gcc, we planned to maintain the code > with g++ in addition to those two. I spent half a day overall and > discovered a strange but apparent ignorance of final users that > the gcc team has. We will have to wait until the smoke clears and > personal ambitions settle down. I can understand this.... > Finally, Chris, I appreciate your efforts to interpret emails to > the two parties, but I can only stand by what I wrote ---- > I am pretty sure that PCs dominate general purpose computers, > and that, independently, RedHat is dominating Linux installations -- > I saw this published ;-) (I think you slightly misquoted me on this) I probably did :-) At any rate, the one thing that I think RedHat consistantly overlooks is binary package dependencies (which Debian has, believe me, this is not to toot our horn, just an example). I think alot of the misbuilt RPMs that I've run into relate to this. In this case, I'm pretty sure that ignorance of that issue, coupled with lack of general knowledge on the packager's part (hence the ownership issues) and also lack of general libtool knowledge (argh) probably defeated that set of RPMs. I would strongly recommend building it from source for two reasons: ensuring that nothing was "added" to the RPMs in question and also so that you can tailor the installation to your particular systems. I have a more than rudimentary understanding of gcc and the RPM format, but wouldn't even attempt making a set of RPMs unless I was POSITIVE that I could make them as portable as possible (obviously something overlooked by the packager of the RPMs in contrib). At any rate, I'll bow out of this discussion again :-) I understand both sides, but I would tend to agree with the "build it from the source" advice on the list (I know I usually do, having an EV56 Alpha). C From gcc-return-8830-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 00:42:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21139 invoked by alias); 5 Aug 1999 00:42:10 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21077 invoked from network); 5 Aug 1999 00:41:43 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 5 Aug 1999 00:41:43 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id RAA03318; Wed, 4 Aug 1999 17:41:20 -0700 (PDT) Received: by kankakee.wrs.com (SMI-8.6/SMI-SVR4) id RAA24567; Wed, 4 Aug 1999 17:41:20 -0700 Date: Wed, 4 Aug 1999 17:41:20 -0700 From: mrs@wrs.com (Mike Stump) Message-Id: <199908050041.RAA24567@kankakee.wrs.com> To: imarkov@cs.ucla.edu, jbuck@synopsys.com Subject: Re: Illegal instruction (core dumped) on i586 Cc: binaire@videotron.ca, egcs@egcs.cygnus.com, robertlipe@usa.net > Date: Wed, 04 Aug 1999 16:57:56 -0700 > From: Igor Markov > 2. You can contact people who can do this > > Keeping a mailing list for people who can ensure that binaries > are available isn't hard. Yes, it isn't, and we do this. It is called gcc-announce, and anyone and everyone that cares to be on it is already on it. From gcc-return-8831-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 01:12:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26372 invoked by alias); 5 Aug 1999 01:12:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26354 invoked from network); 5 Aug 1999 01:12:46 -0000 Received: from mail.switchco.com (root@199.190.187.52) by egcs.cygnus.com with SMTP; 5 Aug 1999 01:12:46 -0000 Received: from switchco.com (proteus.swithcho.com [199.190.187.45]) by mail.switchco.com (8.8.0/8.6.12) with ESMTP id UAA26462; Wed, 4 Aug 1999 20:02:17 -0400 Message-ID: <37A8F068.C0158F9A@switchco.com> Date: Wed, 04 Aug 1999 21:01:12 -0500 From: Benjamin Scherrey Reply-To: scherrey@proteus-tech.com Organization: Proteus Technologies, Inc. X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Igor Markov CC: gcc@egcs.cygnus.com Subject: Re: Illegal instruction (core dumped) on i586 References: <199908042213.SAA21387@jwlab.FEITH.COM> <37A8BDE0.3CAFE6DE@cs.ucla.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Igor Markov wrote: > > John, > > thanks... what you are saying makes sense, but my > main suggestion was that egcs maintainers consider > ensuring the availability of good RPMs. This may > include contacting someone who can pack RPMs, or > learning the RPM tricks or... talking to RedHat, > whatever. Please do not consider this as "making > binaries for every trashy system", but rather > "ensuring the utility to major customers". Igor... "major customers" write checks. Ben Scherrey From gcc-return-8832-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 01:19:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28680 invoked by alias); 5 Aug 1999 01:19:11 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28646 invoked from network); 5 Aug 1999 01:19:08 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 5 Aug 1999 01:19:08 -0000 Received: from decepticon.cygnus.com (decepticon.cygnus.com [205.180.230.96]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id SAA27023; Wed, 4 Aug 1999 18:19:07 -0700 (PDT) Received: (bkoz@localhost) by decepticon.cygnus.com (8.8.7/8.6.4) id SAA00355; Wed, 4 Aug 1999 18:19:06 -0700 Date: Wed, 4 Aug 1999 18:19:06 -0700 Message-Id: <199908050119.SAA00355@decepticon.cygnus.com> From: Benjamin Kosnik To: libstdc++@sourceware.cygnus.com, egcs@egcs.cygnus.com, info-gnu@gnu.org Subject: Announcing libstdc++-2.90.6 1999-08-04 Release Notes ------------- The Egcs Standard C++ Library v3, or libstc++-2.90.x, is an ongoing project to implement the ISO 14882 Standard C++ library as described in chapters 17 through 27 and annex D, as a drop-in replacement for the current (ARM-conformant) library. This is the seventh snapshot of the libstdc++ rewrite. It is still incomplet and incorrekt. The Egcs Standard C++ Library v3, or libstc++-2.90.x, follows an open development model, attempting to be fully buzzword, bazaar, and GNU compliant. Full details on participating, including contributor guidelines, mailing list subscription, mailing list archives, up-to-date documentation, and various and sundry other details can be found at the following URL: http://sourceware.cygnus.com/libstdc++/ New: --- - basic_string has passed validation, with the cavet empor noted in BUGS. Documentation for string internals has been added to the source code. Ryszard Kabatek has optimized and fixed numerous member functions, in addition to fixes from Alfred Minarik and Vadim Egorov. - Include-path optimizations. - The library and testsuite have been made namespace friendly thanks to Alfred Minarik - bits/std_cmath.h and math/mathconf tweaks by Gabriel Dos Reis. - complex, valarray, gslice work by Gabriel Dos Reis. - Preliminary port to cygwin by Mumit Khan - basic_stringbuf was re-implemented to fix problems with ostringstreams. - ios_base and basic_ios data member optimization/clarification. The ios heirarchy now has preliminary facet caching. - istream::ws, getline, and all extraction operators were fixed and have undergone preliminary testing. - Additional documentation by Phil Edwards. - Many, many bug fixes. More info is available on the project website, URL as above. -Benjamin From gcc-return-8833-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 01:25:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30131 invoked by alias); 5 Aug 1999 01:25:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30114 invoked from network); 5 Aug 1999 01:25:33 -0000 Received: from swen.uwaterloo.ca (129.97.92.100) by egcs.cygnus.com with SMTP; 5 Aug 1999 01:25:33 -0000 Received: from crete.uwaterloo.ca (crete.uwaterloo.ca [129.97.92.34]) by swen.uwaterloo.ca (8.8.8/8.8.8) with ESMTP id VAA01673; Wed, 4 Aug 1999 21:25:30 -0400 (EDT) Received: from localhost (ssingh@localhost) by crete.uwaterloo.ca (8.8.8/8.8.8) with SMTP id VAA03407; Wed, 4 Aug 1999 21:25:29 -0400 (EDT) X-Authentication-Warning: crete.uwaterloo.ca: ssingh owned process doing -bs Date: Wed, 4 Aug 1999 21:25:29 -0400 (EDT) From: Sanjay Singh To: gcc@gcc.gnu.org cc: kbkrauel@kingcong.uwaterloo.ca Subject: problems installing on NeXT Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello. I have gcc 2.95 and I am trying to install it on a NeXT with OpenStep, but the configure script isn't completing because the dirname utility isn't present on the system. I gather it's important since it parses the path out of a fully qualified expression. I am wondering if I should try to make a script from: ## this sed command emulates the dirname command dstdir=`echo $dst | sed -e 's,[^/]*$,,;s,/$,,;s,^$,.,'` and put in in a system directory... Or if there is some other way to get GCC going on a NeXT. Please advise. Thanks. S. From gcc-return-8834-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 01:28:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31367 invoked by alias); 5 Aug 1999 01:28:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31339 invoked from network); 5 Aug 1999 01:28:42 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 5 Aug 1999 01:28:42 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id WAA06017; Wed, 4 Aug 1999 22:24:31 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id WAA24927; Wed, 4 Aug 1999 22:24:31 -0300 (EST) To: "Jussi Lassila" Cc: , gcc-patches@gcc.gnu.org Subject: [FAQ patch] Re: GCC 2.95 Build succesful on hppa2.0-hp-hpux10.20 References: <001001bede48$539248e0$0687edc3@comptel.com> From: Alexandre Oliva Date: 04 Aug 1999 22:28:24 -0300 In-Reply-To: "Jussi Lassila"'s message of "Wed, 4 Aug 1999 10:09:43 +0300" Message-ID: Lines: 21 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= On Aug 4, 1999, "Jussi Lassila" wrote: > For some reason though, when I used the --with-gnu-as option, it did > not find/use the gnu assembler --with-gnu-as does not tell gcc to *look* for GNU as, it just tells it to assume the assembler it will find is GNU as. As stated in the FAQ, gcc -print-search-dirs tells which directories it searches, and only if it does not find an assembler in any of those directories will it search the PATH. So you have to create links before you start building, or create them in the build directories too, as explained in the patch below. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=gnu-as-ld.patch Index: faq.html =================================================================== RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/faq.html,v retrieving revision 1.139 *** faq.html 1999/07/30 05:30:55 1.139 --- faq.html 1999/08/05 01:27:15 *************** *** 398,403 **** --- 398,410 ----
+

GCC searches the PATH for an assembler and a loader, but it only + does so after searching a directory list hard-coded in the gcc + executables. Since, on most platforms, the hard-coded list includes + directories in which the system asembler and loader can be found, you + may have to take one of the following actions to arrange that gcc uses + the GNU versions of those programs.

+

To ensure that GCC finds the GNU assembler (the GNU loader), which are required by some configurations, you should configure these with the same --prefix option as you used *************** *** 407,422 ****

Another alternative is to create links to GNU as and ld in any of the directories printed by the command `gcc -print-search-dirs | grep '^programs:''. The link to `ld' should be named ! `real-ld' if `ld' already exists.

!

GCC 2.95 allows you to specify the full pathname of ! the assembler and the linker to use. The configure flags are `--with-as=/path/to/as' and `--with-ld=/path/to/ld'. GCC will try to use these pathnames before looking for `as' or `(real-)ld' in the standard search dirs. If, at configure-time, the specified programs are found to be GNU utilities, `--with-gnu-as' and `--with-gnu-ld' need not be ! used; these flags will be auto-detected.

cpp: Usage:... Error

--- 414,435 ----

Another alternative is to create links to GNU as and ld in any of the directories printed by the command `gcc -print-search-dirs | grep '^programs:''. The link to `ld' should be named ! `real-ld' if `ld' already exists. If such links do ! not exist while you're compiling GCC, you may have to create them in ! the build directories too, within the gcc directory ! and in all the gcc/stage* subdirectories.

!

GCC 2.95 allows you to specify the full pathname of the assembler ! and the linker to use. The configure flags are `--with-as=/path/to/as' and `--with-ld=/path/to/ld'. GCC will try to use these pathnames before looking for `as' or `(real-)ld' in the standard search dirs. If, at configure-time, the specified programs are found to be GNU utilities, `--with-gnu-as' and `--with-gnu-ld' need not be ! used; these flags will be auto-detected. One drawback of this option ! is that it won't allow you to override the search path for assembler ! and linker with command-line options -B/path/ if the ! specified filenames exist.

cpp: Usage:... Error

--=-=-= -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them --=-=-=-- From gcc-return-8835-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 02:41:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8612 invoked by alias); 5 Aug 1999 02:41:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8581 invoked from network); 5 Aug 1999 02:41:19 -0000 Received: from c1000907-b.sttls1.wa.home.com (root@24.0.226.45) by egcs.cygnus.com with SMTP; 5 Aug 1999 02:41:19 -0000 Received: from localhost (mjc@localhost) by c1000907-b.sttls1.wa.home.com (8.6.12/8.6.9) with ESMTP id TAA22272 for ; Wed, 4 Aug 1999 19:41:07 -0700 Date: Wed, 4 Aug 1999 19:41:07 -0700 (PDT) From: Mark Crosland To: gcc@gcc.gnu.org Subject: Re: Trying to build egcs-1.1.2 on dynix/sequent platform... In-Reply-To: <10989.933790511@upchuck.cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I added "#define NO_SYS_SIGLIST 1" to auto-host.h and things went much further. stage1 completed, and then late(?) in the stage2 build, after it re-configures a bunch of stuff, it tries to build libio again and things get a little squirly. The compiler can't seem to resolve functions that are being used in the class that they are defined in. e.g., class A { int B(); int C() { B(); } }; will result in the compiler stopping with an error in function C(), claiming that class A does not contain a function called B(). I tried some serious flailing at the code, just to see if this was a small hicup (replacing the offending calls with the (small) functions they call), but the next file died the same death. The following is the last bit of the make output, maybe someone will say, "oh yeah, i remember this..." (or maybe not :) /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/ioftell.c -o pic/ioftell.o /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/ioftell.c test x"no" != xyes ||\ /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/iovsscanf.c -o pic/iovsscanf.o /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/iovsscanf.c test x"no" != xyes ||\ /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/iovsprintf.c -o pic/iovsprintf.o /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/iovsprintf.c test x"no" != xyes ||\ /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/ioprims.c -o pic/ioprims.o /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/ioprims.c test x"no" != xyes ||\ /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/iostrerror.c -o pic/iostrerror.o /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/iostrerror.c test x"no" != xyes ||\ /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/cleanup.c -o pic/cleanup.o /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/cleanup.c test x"no" != xyes ||\ /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/stdfiles.c -o pic/stdfiles.o /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -O -I. -I../../../libio ../../../libio/stdfiles.c rm -rf libio.a ar cr libio.a filedoalloc.o floatconv.o genops.o fileops.o iovfprintf.o iovfscanf.o ioignore.o iopadn.o iofgetpos.o iofread.o iofscanf.o iofsetpos.o iogetdelim.o iogetline.o ioprintf.o ioseekoff.o ioseekpos.o outfloat.o strops.o iofclose.o iopopen.o ioungetc.o peekc.o iogetc.o ioputc.o iofeof.o ioferror.o iofdopen.o iofflush.o iofgets.o iofopen.o iofprintf.o iofputs.o iofwrite.o iogets.o ioperror.o ioputs.o ioscanf.o iosetbuffer.o iosetvbuf.o iosprintf.o iosscanf.o ioftell.o iovsscanf.o iovsprintf.o ioprims.o iostrerror.o cleanup.o stdfiles.o true libio.a test x"no" != xyes || \ /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -g -O2 -fno-implicit-templates -I. -I../../../libio -nostdinc++ ../../../libio/builtinbuf.cc -o pic/builtinbuf.o /users/markc/sw/gcc/gcc-2.95/objdir/gcc/xgcc -B/users/markc/sw/gcc/gcc-2.95/objdir/gcc/ -B/users/markc/sw/gcc/i386-sequent-sysv4/bin/ -c -g -O2 -fno-implicit-templates -I. -I../../../libio -nostdinc++ ../../../libio/builtinbuf.cc In file included from ../../../libio/builtinbuf.h:32, from ../../../libio/builtinbuf.cc:29: ../../../libio/streambuf.h: In method `void ios::clear(int = 0)': ../../../libio/streambuf.h:212: `class ios' has no member named `_throw_failure' ../../../libio/streambuf.h: In method `void ios::set(int)': ../../../libio/streambuf.h:214: `class ios' has no member named `_throw_failure' ../../../libio/streambuf.h: In method `void ios::setstate(int)': ../../../libio/streambuf.h:216: `class ios' has no member named `_throw_failure' ../../../libio/streambuf.h: In method `ios::operator void *() const': ../../../libio/streambuf.h:222: `class ios' has no member named `fail' ../../../libio/streambuf.h: In method `int ios::operator !() const': ../../../libio/streambuf.h:223: `class ios' has no member named `fail' ../../../libio/streambuf.h: In method `void ios::exceptions(int)': ../../../libio/streambuf.h:227: `class ios' has no member named `_throw_failure' ../../../libio/streambuf.h: In method `class streambuf * ios::rdbuf(streambuf *)': ../../../libio/streambuf.h:231: `class ios' has no member named `clear' make[2]: *** [builtinbuf.o] Error 1 make[2]: Leaving directory `/users/markc/sw/gcc/gcc-2.95/objdir/i386-sequent-sysv4/libio' make[1]: *** [all-target-libio] Error 2 make[1]: Leaving directory `/users/markc/sw/gcc/gcc-2.95/objdir' make: *** [bootstrap-lean] Error 2 Clues? Thanks, Mark Crosland On Wed, 4 Aug 1999, Jeffrey A Law wrote: > In message e.com>you write: > > > > Hello, I am trying to build egcs-1.1.2 on a dynix/sequent platform. > > uname -a > > DYNIX/ptx engdevq1 4.0 V4.4.2 i386 > Nobody's had success with a dynix/sequent system that I'm aware of. You'll > have to do some debugging/fixing yourself. We would greatly appreciate it > if you could forward any fixes to the gcc-patches list. > > Apparently dynix's handling of sys_siglist is different from most other > systems, which may require you to define SYS_SIGLIST_DECLARED or NO_SYS_SIGLIST > to change the compiler's strategy for handling the signal list variable. > > > jeff > From gcc-return-8836-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 03:26:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13374 invoked by alias); 5 Aug 1999 03:26:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13352 invoked from network); 5 Aug 1999 03:26:30 -0000 Received: from unknown (HELO smtpmta2.i2.com) (208.193.77.22) by egcs.cygnus.com with SMTP; 5 Aug 1999 03:26:30 -0000 Received: by smtpmta2.i2.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 862567C4.0012E1C3 ; Wed, 4 Aug 1999 22:26:14 -0500 X-Lotus-FromDomain: I2TECH From: "Matt Conway" To: gcc@gcc.gnu.org Message-ID: <862567C4.0012E082.00@smtpmta2.i2.com> Date: Wed, 4 Aug 1999 23:26:20 -0400 Subject: Successful build on hppa2.0w-hp-hpux11.00 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline uname -a: HP-UX emu B.11.00 U 9000/800 71880 unlimited-user license config.guess: hppa2.0w-hp-hpux11.00 Using binutils-990804 and --with-gnu-as From gcc-return-8837-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 04:01:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18505 invoked by alias); 5 Aug 1999 04:01:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18490 invoked from network); 5 Aug 1999 04:01:36 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 5 Aug 1999 04:01:36 -0000 Received: from cs.ucla.edu (ts36-5.wla.ts.ucla.edu [164.67.22.66]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id VAA10478; Wed, 4 Aug 1999 21:01:35 -0700 (PDT) Message-ID: <37A90D55.38F2AE17@cs.ucla.edu> Date: Wed, 04 Aug 1999 21:04:37 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@egcs.cygnus.com Subject: In case anyone's interested [Fwd: GCC-2.95 rpm] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit this is the response from the author of faulty RPMs Binaire wrote: > > Hello Igor Markov > Seem that you have trouble with my gcc rpm ; > If i understand well the probleme came from libstdc++ > When upgrading to gcc-2.95 it come with a new version of libstdc++ ; > incompatible with old version ... that why i have included a old compatible > version like the one of redhat include with egcs-1.1.2 ; > But it's very difficult to include all compatible libraries .. the one that > come with redhat 5.2 is libstdc++.2.9.0 ; this one is rename to > libstdc++-2.libc6.so.2 in redhat 6 ; and i don't have all binairies > librairies at hand . > To make sure that your c++ binairies will run with the new gcc .. > recompile them so they will be linked to the new libstdc++ ... I'll refrain from further comments on this (and expect no Itoldya's in my mailbox ;-). Igor P.S. Someone with a RH6.0 system just offered help with RPMs, so I am still hopeful. -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8838-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 05:51:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29436 invoked by alias); 5 Aug 1999 05:51:30 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29420 invoked from network); 5 Aug 1999 05:51:27 -0000 Received: from ftpbox.mot.com (129.188.136.101) by egcs.cygnus.com with SMTP; 5 Aug 1999 05:51:27 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id AAA06432 for ; Thu, 5 Aug 1999 00:51:26 -0500 (CDT)] Received: [from phoenix.cig.mcel.mot.com (phoenix.cig.mcel.mot.com [200.30.2.4]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id AAA21396 for ; Thu, 5 Aug 1999 00:51:25 -0500 (CDT)] Received: from qch1252-01 ([200.30.22.69]) by phoenix.cig.mcel.mot.com (8.8.5/8.8.5/donley-1.1-sol2) with SMTP id NAA24896; Thu, 5 Aug 1999 13:48:04 +0800 (PRC) Message-ID: <000a01bedf06$6532d2e0$45161ec8@qch1252-01.cig.mcel.mot.com> From: "Shi LiJun" To: Subject: Hi, A question for downloading gcc/gc++ Date: Thu, 5 Aug 1999 13:50:06 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01BEDF49.735612E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BEDF49.735612E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear, all As i know , gcc is a very good thing . i read a lot from email , but i found it's difficult to pick up a set of sw that can be used in = sparc/solaris2.5=20 can you help me ? ------=_NextPart_000_0007_01BEDF49.735612E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear, all
 
    As i know , gcc = is a very=20 good thing  . i read a lot from email ,
but i found = it's difficult=20 to pick up a set of sw  that can be used in sparc/solaris2.5 =
can you help = me=20 ?
 
 
------=_NextPart_000_0007_01BEDF49.735612E0-- From gcc-return-8839-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 10:23:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22794 invoked by alias); 5 Aug 1999 10:23:57 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22774 invoked from network); 5 Aug 1999 10:23:55 -0000 Received: from unknown (HELO hotmail.com) (209.185.241.235) by egcs.cygnus.com with SMTP; 5 Aug 1999 10:23:55 -0000 Received: (qmail 2960 invoked by uid 0); 5 Aug 1999 10:23:27 -0000 Message-ID: <19990805102327.2959.qmail@hotmail.com> Received: from 193.140.236.112 by www.hotmail.com with HTTP; Thu, 05 Aug 1999 03:23:27 PDT X-Originating-IP: [193.140.236.112] From: "Emir Uner" To: gcc@gcc.gnu.org Subject: What is generic i386-elf target? Date: Thu, 05 Aug 1999 03:23:27 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Hi, I want to ask a question but it may be a bit foolish. I've seen that there is a generic i386-elf target. What does it mean "generic"? And how can it be used. -emir ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From gcc-return-8840-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 11:17:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27031 invoked by alias); 5 Aug 1999 11:17:13 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26994 invoked from network); 5 Aug 1999 11:17:02 -0000 Received: from shaman.fnspo.cz (194.108.54.253) by egcs.cygnus.com with SMTP; 5 Aug 1999 11:17:02 -0000 Received: (qmail 9577 invoked from network); 5 Aug 1999 11:16:31 -0000 Received: from unknown (HELO g30.fnspo.cz) (172.16.1.12) by 172.16.1.253 with SMTP; 5 Aug 1999 11:16:31 -0000 Received: from David.Turai@fnspo.cz@g30.fnspo.cz () by g30.fnspo.cz () with ESMTP id NAA11404 for ; Thu, 5 Aug 1999 13:14:23 +0200 (MESZ) Message-ID: <37A970D3.270C3E66@fnspo.cz> Date: Thu, 05 Aug 1999 13:09:08 +0200 From: David Turai X-Mailer: Mozilla 4.06 [en] (Win98; I) MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: gcc for z80 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have simple question. Exists GCC for z80. Thak you for answer. David Turai From gcc-return-8841-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 12:00:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30956 invoked by alias); 5 Aug 1999 12:00:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30941 invoked from network); 5 Aug 1999 12:00:30 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 5 Aug 1999 12:00:30 -0000 Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id IAA24053; Thu, 5 Aug 1999 08:00:28 -0400 (EDT) Received: from localhost by world.std.com (TheWorld/Spike-2.0) id AA09645; Thu, 5 Aug 1999 08:00:28 -0400 Date: Thu, 5 Aug 1999 08:00:28 -0400 From: Steven W Orr Reply-To: steveo@world.std.com To: Igor Markov Cc: John Wehle , gcc@egcs.cygnus.com Subject: Re: Illegal instruction (core dumped) on i586 In-Reply-To: <37A8BDE0.3CAFE6DE@cs.ucla.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm inclined to agree on this one. As an example, fetchmail is delivered as a .tar.gz file as well as a src.rpm. Lots of software is now coming that way. When I install *anything* I always look for an rpm to install from. *If* the tar.gz file is properly set up, i.e., if configure really works 100% correctly, then the spec file for the rpm, by definition, becomes trivial. I'm not going to go over the pros and cons of rpm vs. tgz but I think it's a safe bet that anyone who doesn't use rpm is running on a system that's just not rpm based. If you have it you use it without question. Is there anything else I can say to help stimulate the production of gcc in both forms? -- ----------Time flies like the wind. Fruit flies like a banana.---------------- --------Stranger things have happened but none stranger than this.------------- Steven W. Orr steveo@world.std.com ---------------"Listen to me! We are all individuals."------------------------- On Wed, 4 Aug 1999, Igor Markov wrote: => => John, => => thanks... what you are saying makes sense, but my => main suggestion was that egcs maintainers consider => ensuring the availability of good RPMs. This may => include contacting someone who can pack RPMs, or => learning the RPM tricks or... talking to RedHat, => whatever. Please do not consider this as "making => binaries for every trashy system", but rather => "ensuring the utility to major customers". => I don't suppose many windows applications depend => on gcc and libs, neither on Solaris or HP-UX. => gcc is the default compiler on Linux. Things => are very difft here. => => Igor => From gcc-return-8842-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 14:41:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9953 invoked by alias); 5 Aug 1999 14:41:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9903 invoked from network); 5 Aug 1999 14:40:50 -0000 Received: from field.videotron.net (205.151.222.108) by egcs.cygnus.com with SMTP; 5 Aug 1999 14:40:50 -0000 Received: from binaire.cx ([24.200.35.156]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.03.02.17.58.p5) with ESMTP id <0FFZ006D8Y3D3Z@field.videotron.net> for egcs@egcs.cygnus.com; Thu, 5 Aug 1999 10:40:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by binaire.cx (8.9.3/8.9.3) id KAA05917; Thu, 05 Aug 1999 10:40:18 -0400 Date: Thu, 05 Aug 1999 14:09:57 +0000 From: Vu Hung Quan Subject: gcc-2.95 rpm To: egcs@egcs.cygnus.com Cc: imarkov@cs.ucla.edu Message-id: <99080514401800.19963@binaire.cx> MIME-version: 1.0 X-Mailer: KMail [version 1.0.26] Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 8bit Hi , I have uploaded a new rpm version of gcc-2.95 in rh contrib ftp , these will be avalaible shortly : gcc-2.95-4.src.rpm cpp-2.95-4.i386.rpm gcc-2.95-4.i386.rpm gcc-c++-2.95-4.i386.rpm gcc-chill-2.95-4.i386.rpm gcc-g77-2.95-4.i386.rpm gcc-java-2.95-4.i386.rpm gcc-libgcj-2.95-4.i386.rpm gcc-objc-2.95-4.i386.rpm libstdc++-2.95-4.i386.rpm And a i686 version Of note these gcc has been compiled with binutils-2.9.1.0.25 and i also put a rpm of that in contrib rh ftp For compatibilites problemes with libstdc++ : I have include with libstdc++ all the old version of libstdc++ : libg++.so.2.7.2.8 libstdc++.so.2.7.2.8 libstdc++.so.2.8.0 libstdc++-2-libc6.1-1.2.9.0 Libstdc++.so.2.9.0 is renamed by redhat 6 to libstdc++-2-libc6.1-1-2.9.0 but in mankade 6 it's libstdc++.so.2.9.0 with a link from libstdc++-2.9-libc6.1-1.2.9.0 ; so if a binairy is compiled under mankade it will be linked to libstdc++.so.2.9.0 and if compiled under redhat 6 it will be linked to libstdc++-2-libc6.1-1-2.9.0 . I have decided to include only redhat version so there is no libstdc++.so.2.9.0 . If you have trouble with libstdc++ , may be you could make a link libstdc++.so.2.9.0 to libstdc++-2-libc6.1-1.2.9.0 , but a better solution is to recompiled them to be linked to a new libstdc++ . These rpm use de same naming convention from redhat egcs and will be installed in the same place . These rpm can be relocated to another subdir with rpm --relocate ( rpm ... --relocate /usr=/opt/usr --relocate /lib=/opt/lib ) Another thing is that c++filt is included with binutils-2.9.1.0.25 and when compiling gcc i have another version of c++filt ; i decide not to included them in gcc . Please correct me if i am wrong . By the way redhat contrib ftp is only for testing purpose : a good use is to d/l src.rpm and remake them with rpm --rebuild for your machine ; you will need a recent binutils . I have compiled theses binairies with -O3 ; the i686 is exclusively for pentiumpro , II, III only as it was compiled with -mpentiumpro -march=pentiumpro . I have tested gcc-2.95 with all my rpm packages , and it work without an internal compiler error , some package need -fno-strict-aliasing like kernel , XFree86 . python ; kde-1.1.1 can't be compiled under gcc-2.95 but kde-1.1.2pre can . Please do not annoy gcc people about compatiblity error . Thank . -- Vu Hung Quan ,md, frcpc binaire@videotron.ca From gcc-return-8843-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 14:42:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10150 invoked by alias); 5 Aug 1999 14:42:05 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9957 invoked from network); 5 Aug 1999 14:41:34 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 5 Aug 1999 14:41:34 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id HAA25754; Thu, 5 Aug 1999 07:40:22 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id HAA16804; Thu, 5 Aug 1999 07:40:21 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id HAA07951; Thu, 5 Aug 1999 07:40:21 -0700 Message-Id: <199908051440.HAA07951@atrus.synopsys.com> Subject: Re: Illegal instruction (core dumped) on i586 To: steveo@world.std.com Date: Thu, 5 Aug 99 7:40:21 PDT Cc: imarkov@cs.ucla.edu, john@feith.com, gcc@egcs.cygnus.com In-Reply-To: ; from "Steven W Orr" at Aug 5, 99 8:00 am X-Mailer: ELM [version 2.3 PL11] > I'm inclined to agree on this one. As an example, fetchmail is delivered > as a .tar.gz file as well as a src.rpm. fetchmail is a completely independent program. Installing fetchmail won't change the behavior of other programs, and possibly make them stop working. Installing a new gcc package with a binary-incompatible C++ library is another matter, one best left to the folks who put out the distribution. > Is there anything else I can say to help stimulate the production of gcc > in both forms? Even if we wanted to do it, there's no one that we can order to do the job (the release manager and principal developers have their hands full and, to the extent that they have free time, would prefer to improve the compiler to dealing with packaging issues). It would need to be done by a skilled, careful volunteer who would not announce the result until he/she had conducted thorough testing. libstdc++/libc collisions are a frequent problem on Linux, and this has to be managed carefully when doing binary distributions. Even then, the RPM should not install the new compiler in /usr/bin, wiping out the system compiler. For one thing, people would no longer be able to build Linux kernels without manual intervention (as one must specify -fno-strict-aliasing to build the kernel correctly). From gcc-return-8844-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 14:49:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11507 invoked by alias); 5 Aug 1999 14:49:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11475 invoked from network); 5 Aug 1999 14:49:45 -0000 Received: from gwdu42.gwdg.de (HELO gwdu12.gwdg.de) (134.76.10.26) by egcs.cygnus.com with SMTP; 5 Aug 1999 14:49:45 -0000 Received: from ras23-071.gwdg.de ([134.76.23.71]) by gwdu12.gwdg.de with smtp (Exim 2.12 #1) id 11COpi-0007iN-00; Thu, 5 Aug 1999 16:49:27 +0200 From: kthomas@gwdg.de (Philipp Thomas) To: Igor Markov Cc: gcc@gcc.gnu.org Subject: Re: Illegal instruction (core dumped) on i586 Date: Thu, 05 Aug 1999 14:49:22 GMT Message-ID: <37b7f252.12949782@mailer.gwdg.de> References: <199908042346.QAA18905@atrus.synopsys.com> <37A8D384.C2E697FE@cs.ucla.edu> In-Reply-To: <37A8D384.C2E697FE@cs.ucla.edu> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Wed, 04 Aug 1999 16:57:56 -0700, Igor Markov = wrote: > Finally, if you guys are stressed out and don't have time,=20 > why don't you just put a disclaimer on egcs site ----=20 > "will be done later", so that I don't really plan on using gcc > (aftering getting burnt by expecting a release in the first half > of July). Ok, you asked for it, so better get your asbestos underwear. Are you trying to troll or are you really such an ignorant fool. There = will be no "will be done later" because IT IS NOT OUR JOB, period. And about = getting burnt: could it be that you somehow missed that this is volunteer work ? = So did you help us in reaching that *tentative* goal by contributing ? No ? = Then shut up and try growing up. As has been told to you, we only do source releases. Isn't that clear = enough ? It's the job of the *vendor* of the distribution you use to supply you = with the binary rpm, not the gcc team. So go complaining to RedHat, but you'd better be prepared for unpleasant answers from them because you seem to have missed the disclaimer for = stuff in the contrib directory, namely that everything there is *not* official = RedHat stuff and you use it at your own risk. You did so, it broke, you get to = keep the pieces. If you don't know how to compile all the necessary packages, wait for the official announcement from the vendor of your choice. But STOP whining = and blaming others because YOU didn't have a clue and stop insulting those of= us that invested their free time to make gcc 2.95 happen. Try to get the clue you very obviously don't have, try to listen to what people tell you, and no, reading "Linux-Hacker in 24 hours" is not = sufficient. Philipp --=20 Nothing would please me more than being able to hire ten programmers and deluge the hobby market with good software. -- Bill Gates, 1976 From gcc-return-8845-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 14:49:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11581 invoked by alias); 5 Aug 1999 14:49:53 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11552 invoked from network); 5 Aug 1999 14:49:51 -0000 Received: from gwdu42.gwdg.de (HELO gwdu12.gwdg.de) (134.76.10.26) by egcs.cygnus.com with SMTP; 5 Aug 1999 14:49:51 -0000 Received: from ras23-071.gwdg.de ([134.76.23.71]) by gwdu12.gwdg.de with smtp (Exim 2.12 #1) id 11COpm-0007iN-00; Thu, 5 Aug 1999 16:49:31 +0200 From: kthomas@gwdg.de (Philipp Thomas) To: Igor Markov Cc: gcc@gcc.gnu.org Subject: Re: Illegal instruction (core dumped) on i586 Date: Thu, 05 Aug 1999 14:49:27 GMT Message-ID: <37b4ee53.11926577@mailer.gwdg.de> References: <199908042213.SAA21387@jwlab.FEITH.COM> <37A8BDE0.3CAFE6DE@cs.ucla.edu> In-Reply-To: <37A8BDE0.3CAFE6DE@cs.ucla.edu> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Wed, 04 Aug 1999 15:25:36 -0700, Igor Markov = wrote: >"ensuring the utility to major customers" Amazing, you still don't seem to get it. Pardon, Customers ? Did we charge you for downloading ? So stop talking = of customers. Yes, Linux is an important platform for the gcc team and much effort has gone into making gcc work on that platform, provided that it = is being built by someone who knows how to do it. This is free software, created by volunteers. So, as I already wrote in another mail, get a clue or move to an OS where you pay for what you get = and thus have a right to demand anything. Philipp --=20 Nothing would please me more than being able to hire ten programmers and deluge the hobby market with good software. -- Bill Gates, 1976 From gcc-return-8846-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 15:04:23 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16115 invoked by alias); 5 Aug 1999 15:04:22 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16088 invoked from network); 5 Aug 1999 15:04:20 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 5 Aug 1999 15:04:20 -0000 Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id LAA16821; Thu, 5 Aug 1999 11:04:18 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com by world.std.com (TheWorld/Spike-2.0) id AA26698; Thu, 5 Aug 1999 11:03:57 -0400 Received: (qmail 17406 invoked by uid 500); 5 Aug 1999 15:03:14 -0000 Date: 5 Aug 1999 15:03:14 -0000 Message-Id: <19990805150314.17405.qmail@deer> To: jbuck@synopsys.COM Cc: steveo@world.std.com, imarkov@cs.ucla.edu, john@feith.com, gcc@egcs.cygnus.com Cc: craig@jcb-sc.com In-Reply-To: <199908051440.HAA07951@atrus.synopsys.com> (message from Joe Buck on Thu, 5 Aug 99 7:40:21 PDT) Subject: Re: Illegal instruction (core dumped) on i586 References: <199908051440.HAA07951@atrus.synopsys.com> I agree with all of the sentiment about the GCC team not having producing RPM's as one of its functions. I'd like to add that my impression is that not just GCC, but GNU generally, could benefit the community by looking over the various package-management systems (RPMs, and doesn't Debian have one?) and figuring out, at least, how best to architect, design, and implement the relevant bits of GNU products so GNU maintainers, as well as packagers, have an easier life producing robust, portable products. tq vm, (burley) From gcc-return-8847-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 15:12:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18641 invoked by alias); 5 Aug 1999 15:12:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18623 invoked from network); 5 Aug 1999 15:12:51 -0000 Received: from cg667526-a.adubn1.nj.home.com (HELO drow.them.org) (mail@24.2.213.175) by egcs.cygnus.com with SMTP; 5 Aug 1999 15:12:51 -0000 Received: from drow by drow.them.org with local (Exim 3.02 #1 (Debian)) id 11CPDJ-0005sr-00; Thu, 05 Aug 1999 11:13:49 -0400 Date: Thu, 5 Aug 1999 11:13:49 -0400 From: Daniel Jacobowitz To: craig@jcb-sc.com Cc: jbuck@synopsys.COM, steveo@world.std.com, imarkov@cs.ucla.edu, john@feith.com, gcc@egcs.cygnus.com Subject: Re: Illegal instruction (core dumped) on i586 Message-ID: <19990805111349.A22564@them.org> References: <199908051440.HAA07951@atrus.synopsys.com> <19990805150314.17405.qmail@deer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.12i In-Reply-To: <19990805150314.17405.qmail@deer>; from craig@jcb-sc.com on Thu, Aug 05, 1999 at 03:03:14PM -0000 On Thu, Aug 05, 1999 at 03:03:14PM -0000, craig@jcb-sc.com wrote: > I agree with all of the sentiment about the GCC team not having > producing RPM's as one of its functions. > > I'd like to add that my impression is that not just GCC, but GNU > generally, could benefit the community by looking over the various > package-management systems (RPMs, and doesn't Debian have one?) and > figuring out, at least, how best to architect, design, and implement > the relevant bits of GNU products so GNU maintainers, as well as > packagers, have an easier life producing robust, portable products. And as one of the people who makes the Debian packages (yes, we have one), I can say that GCC has gone a long way down that road already. While the packaging is somewhat complex, it's not at all as bad as I would have expected from a project of this size. Dan /--------------------------------\ /--------------------------------\ | Daniel Jacobowitz |__| SCS Class of 2002 | | Debian GNU/Linux Developer __ Carnegie Mellon University | | dan@debian.org | | dmj+@andrew.cmu.edu | \--------------------------------/ \--------------------------------/ From gcc-return-8848-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 16:02:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24219 invoked by alias); 5 Aug 1999 16:02:09 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24201 invoked from network); 5 Aug 1999 16:02:03 -0000 Received: from gate2.cae.ca (HELO relay2.cae.ca) (142.39.200.51) by egcs.cygnus.com with SMTP; 5 Aug 1999 16:02:03 -0000 Message-ID: <1E2D00318925D3118C340090277193582D22BF@caemsx01.cae.ca> From: Alexander Loksh To: "'gcc@gcc.gnu.org'" Subject: Need some help and info Date: Thu, 5 Aug 1999 11:58:18 -0400 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hi ! I have the program which opens executable and extracts information about the static and global variables. This program was designed for the executable files which were created by the GCC compiler 2.7.2. on Linux version 2.0.27 for PC When the new kernel 2.2 was installed with the GCC 2.7.2.3 compiler and 0.5.24 Fortran compiler I found that my program doesn't work. The reason of it is that the "stabs" which described the symbols were changed. After running the objdump --stabs I found, for example the following: The variable which is defined like int i ; is described for 2.7.2 version: 305 STSYM 0 2 08050c78 5236 i:V20 For the 2.7.2.3 version it's description is 337 STSYM 0 2 080511a0 7580 i:V(0,20) Because of this I have some questions. The only code which I have is the plain C and Fortran-77. 1. By using the 2.7.2.3 compiler can I generate the same type of executable like using 2.7.2 compiler. ( in terms that "objdump -- stabs" will give me the same result) ? I tried to supress creation of the gdb extensions using -gstabs option but managed to do this only for the C-files, not Fortran. 2. If there is no backward compatibility in the terms described above can I use the package which is created by compiling gcc-2.7.2.3 and fortran 0.5.18 together( I can build it like it described in README file) ? Thank you Alexander Loksh loksh@cae.ca From gcc-return-8849-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 17:06:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1407 invoked by alias); 5 Aug 1999 17:06:07 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1271 invoked from network); 5 Aug 1999 17:05:54 -0000 Received: from nuxi.cs.ucdavis.edu (HELO relay.nuxi.com) (@169.237.7.38) by egcs.cygnus.com with SMTP; 5 Aug 1999 17:05:54 -0000 Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id KAA03501; Thu, 5 Aug 1999 10:05:52 -0700 (PDT) (envelope-from obrien) Message-ID: <19990805100551.B3426@nuxi.com> Date: Thu, 5 Aug 1999 10:05:51 -0700 From: "David O'Brien" To: Igor Markov Cc: egcs@egcs.cygnus.com Subject: Re: Illegal instruction (core dumped) on i586 Reply-To: obrien@NUXI.com References: <37A8ACF5.E1B1C3F7@cs.ucla.edu> <19990804164017.C13940@rjlhome.sco.com> <37A8BC93.18812C2@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <37A8BC93.18812C2@cs.ucla.edu>; from Igor Markov on Wed, Aug 04, 1999 at 03:20:03PM -0700 X-Operating-System: FreeBSD 3.2-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 On Wed, Aug 04, 1999 at 03:20:03PM -0700, Igor Markov wrote: > > This is the 1999 version "All the world is a VAX running BSD" syndrome.... > > Linux is one of major GNU "customers" and egcs was trusted to become > the official version of gcc by GNU. I would expect this assumes some > responsibility. And {Free,Open}BSD are major GNU "customers". Both of these OS's use GNU compiler toolchains exclusively. This includes gcc/g++, libstdc++, gperf, bison, binutils (as & ld), gdb, gprof, etc.. So I demand you wait in line until the GCC maintainers supply *my* binaries! I demand that they do it too! -- David P.S. Being serious, GCC-2.95 binary packages should be on ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-{stable,current} w/in days. I commit the changes to the Ports Collection this morning. From gcc-return-8850-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 17:17:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4600 invoked by alias); 5 Aug 1999 17:17:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4571 invoked from network); 5 Aug 1999 17:17:49 -0000 Received: from sonne.darmstadt.gmd.de (141.12.62.20) by egcs.cygnus.com with SMTP; 5 Aug 1999 17:17:49 -0000 Received: from pc-topaz.darmstadt.gmd.de (pc-topaz [141.12.32.46]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id TAA10156; Thu, 5 Aug 1999 19:17:40 +0200 (MET DST) Received: from darmstadt.gmd.de (localhost [127.0.0.1]) by pc-topaz.darmstadt.gmd.de (8.8.7/8.8.7) with ESMTP id TAA27114; Thu, 5 Aug 1999 19:19:10 +0200 Message-ID: <37A9C789.7303E62@darmstadt.gmd.de> Date: Thu, 05 Aug 1999 19:19:05 +0200 From: Joerg Pommnitz Organization: GMD X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.37 i686) X-Accept-Language: de-DE MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Template-Metaprogramming vs. gcc-2.95 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, out of pure curiosity I tried to compile the Template-Metaprogramming examples from http://home.t-online.de/home/Ulrich.Eisenecker/meta.htm, specifically http://www.prakinf.tu-ilmenau.de/~czarn/meta/metaxmpl.cpp which requires http://www.prakinf.tu-ilmenau.de/~czarn/meta/metactrl Well, it failes. I'm not a C++ language lawyer, so I'm not sure whether metactrl or gcc is at fault (well, actually I suspect at least one missing typename in metaxmpl). I think you should easily be able to reproduce the problem. Just download metaxmpl.cpp and metactrl and g++ -o metaxmpl metaxmpl.cpp -- Regards Joerg GMD-IPSI, Dolivostr. 15, Zimmer 120, D-64293 Darmstadt +49-6151-869-786 (Phone), -818 (FAX) From gcc-return-8851-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 17:49:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10709 invoked by alias); 5 Aug 1999 17:49:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10650 invoked from network); 5 Aug 1999 17:49:01 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 5 Aug 1999 17:49:01 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id KAA17010; Thu, 5 Aug 1999 10:48:50 -0700 (PDT) Received: by kankakee.wrs.com (SMI-8.6/SMI-SVR4) id KAA24732; Thu, 5 Aug 1999 10:48:50 -0700 Date: Thu, 5 Aug 1999 10:48:50 -0700 From: mrs@wrs.com (Mike Stump) Message-Id: <199908051748.KAA24732@kankakee.wrs.com> To: emiruner@hotmail.com, gcc@gcc.gnu.org Subject: Re: What is generic i386-elf target? > From: "Emir Uner" > Date: Thu, 05 Aug 1999 03:23:27 PDT > Hi, I want to ask a question but it may be a bit foolish. I've seen > that there is a generic i386-elf target. What does it mean > "generic"? And how can it be used. Generic means that something is without a lot of specifics, in this case, the specifics are the OS. If you specifically have an OS, you are better off using the specific configuration for that OS. If you don't you would know it, and a generic target would be useful. These generic targets are also useful to base a port on for a specific OS, as then you don't have to worry about special magic, say Linux stuff, being in the files you base your work on. Hope that helps. From gcc-return-8852-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 18:25:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18798 invoked by alias); 5 Aug 1999 18:25:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18769 invoked from network); 5 Aug 1999 18:25:26 -0000 Received: from mailgw1a.lmco.com (192.31.106.7) by egcs.cygnus.com with SMTP; 5 Aug 1999 18:25:26 -0000 Received: from emss02g01.ems.lmco.com (emss02g01.ems.lmco.com [198.7.15.39]) by mailgw1a.lmco.com (8.8.8/8.8.8) with ESMTP id MAA19812; Thu, 5 Aug 1999 12:25:24 -0600 (MDT) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38887) id <0FG0002018I5GN@lmco.com>; Thu, 5 Aug 1999 12:25:23 -0600 (MDT) Received: from lmco.com ([160.205.112.149]) by lmco.com (PMDF V5.2-32 #38887) with ESMTP id <0FG000BYC8I41E@lmco.com>; Thu, 05 Aug 1999 12:25:16 -0600 (MDT) Date: Thu, 05 Aug 1999 12:24:02 -0600 From: Eric Lemings Subject: *_FOR_TARGET Makefile macros To: gcc@gcc.gnu.org, gcc-help@gcc.gnu.org Message-id: <37A9D6C2.A4C7D764@lmco.com> Organization: Lockheed Martin MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.5.1 sun4m) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en What is the difference between * macros (e.g., CFLAGS) and *_FOR_TARGET macros (e.g., CFLAGS_FOR_TARGET) in the top-level Makefile? Thanks, Eric. From gcc-return-8853-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 18:48:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22670 invoked by alias); 5 Aug 1999 18:48:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22617 invoked from network); 5 Aug 1999 18:48:06 -0000 Received: from smtp.ucla.edu (HELO serval.noc.ucla.edu) (169.232.10.57) by egcs.cygnus.com with SMTP; 5 Aug 1999 18:48:06 -0000 Received: from cs.ucla.edu (ts26-10.wla.ts.ucla.edu [164.67.21.103]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id LAA15865; Thu, 5 Aug 1999 11:47:49 -0700 (PDT) Message-ID: <37A9DD04.47C19B1E@cs.ucla.edu> Date: Thu, 05 Aug 1999 11:50:44 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Joe Buck CC: steveo@world.std.com, john@feith.com, gcc@egcs.cygnus.com Subject: a more constructive discussion ;-) References: <199908051440.HAA07951@atrus.synopsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Is there anything else I can say to help stimulate the production of gcc > > in both forms? > > Even if we wanted to do it, there's no one that we can order to do the job > (the release manager and principal developers have their hands full and, > to the extent that they have free time, would prefer to improve the > compiler to dealing with packaging issues). It would need to be done by a > skilled, careful volunteer who would not announce the result until he/she > had conducted thorough testing. libstdc++/libc collisions are a frequent > problem on Linux, and this has to be managed carefully when doing binary > distributions. > > Even then, the RPM should not install the new compiler in /usr/bin, > wiping out the system compiler. For one thing, people would no longer > be able to build Linux kernels without manual intervention (as one > must specify -fno-strict-aliasing to build the kernel correctly). Joe, great words.... esp., > Installing a new gcc package with a binary-incompatible > C++ library is another matter, one best left to the folks who put out > the distribution. interestingly, my suggestion does not conflict with this at all. Given the feedback that I got from this list so far, I would boil it to the following: 1) create a mailing list "gcc-binaries" 2) maintain a page with "binary distributions" 3) maintain "binary packaging test status" on a separate page, i.e., a list of reported successful/failed installation on various systems; 4) keep a list of volunteer "contacts" for various platforms who are willing to assume some limited responsibily and take care of bug reports in the simplest for, the status page will be empty... as long as someone reports success installing smth on some system and a link to the binaries (+ a description of the operation), we can add a line to the status page. If that sounds good, I would be willing to contribute some of my time to this activity. OTOH, I am not sure if I am the best candidate for this as I don't have much experience hacking various systems (never had a non-RH Linux or BSD here, never loged in to an HP or an SGI system, never used gcc on Windows and know little about DLLs, registry etc). I would simply like to show "a good faith effort" here and motivate others and hope that some common sense and the ability to put out Web pages will be useful here (after all, no one can be expected to actually have access to all the systems, so we will have to rely on email and tally successes/failures). comments? Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8854-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 19:21:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29941 invoked by alias); 5 Aug 1999 19:21:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29925 invoked from network); 5 Aug 1999 19:21:24 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 5 Aug 1999 19:21:24 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id NAA22643; Thu, 5 Aug 1999 13:18:29 -0600 X-Mailer: exmh version 2.0.2 To: David Turai cc: gcc@gcc.gnu.org Subject: Re: gcc for z80 Reply-To: law@cygnus.com In-reply-to: Your message of Thu, 05 Aug 1999 13:09:08 +0200. <37A970D3.270C3E66@fnspo.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Aug 1999 13:18:29 -0600 Message-ID: <22640.933880709@upchuck.cygnus.com> From: Jeffrey A Law In message <37A970D3.270C3E66@fnspo.cz>you write: > I have simple question. Exists GCC for z80. Thak you for answer. Cygnus did one for a customer long ago, but it required some disgusting hacks to machine independent parts of the compiler and it was never contributed back. jeff From gcc-return-8855-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 05 19:34:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 332 invoked by alias); 5 Aug 1999 19:34:41 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 313 invoked from network); 5 Aug 1999 19:34:33 -0000 Received: from jl1.quim.ucm.es (root@147.96.5.12) by egcs.cygnus.com with SMTP; 5 Aug 1999 19:34:33 -0000 Received: (from ramon@localhost) by jl1.quim.ucm.es (8.9.3/8.9.3) id VAA02802 for gcc@gcc.gnu.org; Thu, 5 Aug 1999 21:37:27 +0200 Date: Thu, 5 Aug 1999 21:37:27 +0200 From: "Ram'on Garc'ia Fern'andez" To: gcc@gcc.gnu.org Subject: Re: Illegal instruction (core dumped) on i586 Message-ID: <19990805213727.A2789@jl1.quim.ucm.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us What makes the attitude of Igor Markov very unpolite is to place a striking message on the subject line "Illegal instruction (core dumped) on i586" It appears that Igor believes that he is very clever using a subject line that looks as a serious bug report, so that it is more likely to be read. If I where an EGCS developer I would feel offended. You can forgive one newbie who makes a silly question on this mailing list, after all all of we have been newbies. Even if the question is very silly you can answer it if you have free time. But complaing that he does not have a RPM and using such a subject line is a very different thing. It is like those spams messages that have a subject line that looks like a message from a friend. Or like those messages that have a From line like if your admistrator had written them, and then you find out that they offer how to win 3000$ in a day.. This is not acceptable at all. Certainly GCC developers are more polite than me, taking into account that none of them mentioned the bad attitude of Igor. These facts do not encourage GCC development. Even if some developers of GCC are full-time Cygnus employees, many of them are volunteers. Some of them, like Craig, have made a very remarkable work. The combination of Igor messages with Torvalds insults makes the will of these volunteers more difficult to maintain. So end users like me should at least acknowledge the quality of their work. And if we must solve a problem related to end use, we should try first with any Linux expert that we find near us. If we must make a question about instalation, let us find out as much as posible by ourselves, so that developer time can be more productive. Ramon From gcc-return-8856-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 01:22:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2459 invoked by alias); 6 Aug 1999 01:21:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2441 invoked from network); 6 Aug 1999 01:21:48 -0000 Received: from penman.es.mq.edu.au (137.111.94.10) by egcs.cygnus.com with SMTP; 6 Aug 1999 01:21:48 -0000 Received: from perpetuallink.com.au (penman.es.mq.edu.au [137.111.94.10]) by penman.es.mq.edu.au (8.9.0/8.9.0) with ESMTP id LAA00388 for ; Fri, 6 Aug 1999 11:21:42 +1000 (EST) Message-ID: <37AA38A6.AF0114C7@perpetuallink.com.au> Date: Fri, 06 Aug 1999 11:21:42 +1000 From: xxx Organization: Macquarie University X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: zh-CN MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: can't find libstdc++ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, After compiling gcc2.95, thecompilation of a C++ program failed because it can't find libstdc++. How do I fix this problem? How do I tell the system to build libstdc++ when I build gcc2.95? Regards, Ping ping@penman.es.mq.edu.au From gcc-return-8857-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 04:16:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16162 invoked by alias); 6 Aug 1999 04:16:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16147 invoked from network); 6 Aug 1999 04:16:34 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 6 Aug 1999 04:16:34 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id AAA29216 for ; Fri, 6 Aug 1999 00:16:32 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id AAA23620 for gcc@gcc.gnu.org; Fri, 6 Aug 1999 00:16:31 -0400 (EDT) Date: Fri, 6 Aug 1999 00:16:31 -0400 (EDT) From: John Wehle Message-Id: <199908060416.AAA23620@jwlab.FEITH.COM> To: gcc@gcc.gnu.org Subject: CONST_CALL_P questions Content-Type: text 1) What's an example declaration and usage of a const call function? I've been trying unsuccessfully to produce a sample which shows up in a RTL dump. 2) If the INSN has CONST_CALL_P set then does that mean the call has no possible side effects (not even in the parameters passed to the call)? For example the parameters don't have PRE_DEC register notes, volatile memory references, etc. and that the function doesn't write to memory, modify global registers, reference volatile memory, etc. The documentation (a.k.a. the source :-) wasn't completely clear to me on these issues. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-8858-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 05:07:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19907 invoked by alias); 6 Aug 1999 05:07:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19890 invoked from network); 6 Aug 1999 05:07:48 -0000 Received: from dialup090.albatross.co.nz (HELO loki.albatross.co.nz) (nobody@203.97.5.90) by egcs.cygnus.com with SMTP; 6 Aug 1999 05:07:48 -0000 Received: from localhost (psycho@localhost) by loki.albatross.co.nz (8.9.3/8.9.3) with ESMTP id RAA22141; Fri, 6 Aug 1999 17:08:55 +1200 X-Authentication-Warning: loki.albatross.co.nz: psycho owned process doing -bs Date: Fri, 6 Aug 1999 17:08:55 +1200 (NZST) From: Keith Duthie To: xxx cc: gcc@gcc.gnu.org Subject: Re: can't find libstdc++ In-Reply-To: <37AA38A6.AF0114C7@perpetuallink.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 6 Aug 1999, xxx wrote: > All, > > After compiling gcc2.95, thecompilation of a C++ program failed because > it can't > find libstdc++. How do I fix this problem? > > How do I tell the system to build libstdc++ when I build gcc2.95? try "configure --enable-shared" -- Understanding is a three edged sword. Do you *want* to get the point? http://www.albatross.co.nz/~psycho/ O- From gcc-return-8859-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 06:43:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24402 invoked by alias); 6 Aug 1999 06:43:31 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24373 invoked from network); 6 Aug 1999 06:42:54 -0000 Received: from mail.switchco.com (root@199.190.187.52) by egcs.cygnus.com with SMTP; 6 Aug 1999 06:42:54 -0000 Received: from switchco.com (proteus.swithcho.com [199.190.187.45]) by mail.switchco.com (8.8.0/8.6.12) with ESMTP id BAA29413; Fri, 6 Aug 1999 01:38:39 -0400 Message-ID: <37AA90A7.91A6994F@switchco.com> Date: Fri, 06 Aug 1999 02:37:11 -0500 From: Benjamin Scherrey Reply-To: scherrey@proteus-tech.com Organization: Proteus Technologies, Inc. X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: kde-devel@max.tat.physik.uni-tuebingen.de CC: gcc Subject: Re: Trouble building KDE 1.1.1 under Mandrake 6.0 w/ gcc2.95 References: <37A8F3F9.2C939BCA@switchco.com> <37AA7D9D.58837922@switchco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit UPDATED UPDATE - I've uninstalled gcc 2.95 leaving behind pgcc-2.91.66 and it seems to be building just fine. Is this a problem with kde/qt or the new gcc? thanx & later, Ben Scherrey Benjamin Scherrey wrote: > > UPDATE - > > I've now completely re-installed my system sans qt and kde thinking > that perhaps old headers where somewhere getting included. No luck. > Exact same results. Does *anyone* have an idea of what's going > on?!?!?!? Has anyone built KDE 1.1.1 with gcc 2.95? > > please help! > > Ben Scherrey > > PS: Is this the right list for this question? Let me know if not. > > Benjamin Scherrey wrote: > > > > OK - it all started when I was trying to build klyx-0.10.0 and it > > couldn't find some KDE dialog api methods. Figured maybe my KDE was > > old so I blew it away and the installed QT and attempted to build from > > source. D/L'd QT1.44, KDE(base&&libs)1.1.1 and got going. QT is in > > /usr/local/qt and built just fine. I'm running the new release of > > gcc-2.95 on a Mandrake 6.0 intel linux box. QTDIR is setup correctly > > and while trying to build KDElibs (at the libtool step constructing > > libkdecore.la), it complains about all kinds of QT methods being > > defined twice and changing size! > > > > Any ideas? > > > > Ben Scherrey From gcc-return-8860-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 06:55:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26520 invoked by alias); 6 Aug 1999 06:55:44 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26504 invoked from network); 6 Aug 1999 06:55:42 -0000 Received: from custos.foa.se (HELO mercur.foa.se) (150.227.16.253) by egcs.cygnus.com with SMTP; 6 Aug 1999 06:55:42 -0000 Received: from hobbe.lin.foa.se (hobbe.lin.foa.se [150.227.33.76]) by mercur.foa.se (8.9.3/8.9.3) with SMTP id IAA01487; Fri, 6 Aug 1999 08:55:13 +0200 (MET DST) Received: from arnljot.lin.foa.se by hobbe.lin.foa.se (SMI-8.6/SMI-SVR4) id IAA10462; Fri, 6 Aug 1999 08:54:35 +0200 Received: from arnljot.lin.foa.se (IDENT:chj@localhost [127.0.0.1]) by arnljot.lin.foa.se (8.9.3/8.9.3) with ESMTP id IAA04109; Fri, 6 Aug 1999 08:57:04 +0200 Message-Id: <199908060657.IAA04109@arnljot.lin.foa.se> X-Mailer: exmh version 2.0.2 To: Keith Duthie cc: xxx , gcc@gcc.gnu.org Subject: Re: can't find libstdc++ In-reply-to: psycho's message of Fri, 06 Aug 1999 17:08:55 +1200. From: Christian =?iso-8859-1?Q?J=F6nsson?= FOA 72 X-face: 2tQjSw>|IA680lA7r'G9Y[jfoS>tTPw4-B#mQo_C+{6>^DWZP`o.h On Fri, 6 Aug 1999, xxx wrote: > = > > All, > > = > > After compiling gcc2.95, thecompilation of a C++ program failed becau= se > > it can't > > find libstdc++. How do I fix this problem? > > = > > How do I tell the system to build libstdc++ when I build gcc2.95? > try "configure --enable-shared" Hmm, that should not make a difference in this case, would it? If the = ``make bootstrap'' succeeded *without* the --enable-shared, there would = have been a static libstdc++.a in a place that c++ ``run as linker'' woul= d = have found it (libstdc++.a) , right? /ChJ From gcc-return-8861-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 08:14:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1519 invoked by alias); 6 Aug 1999 08:14:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1504 invoked from network); 6 Aug 1999 08:14:29 -0000 Received: from dialup071.albatross.co.nz (HELO loki.albatross.co.nz) (203.97.5.71) by egcs.cygnus.com with SMTP; 6 Aug 1999 08:14:29 -0000 Received: from localhost (psycho@localhost) by loki.albatross.co.nz (8.9.3/8.9.3) with ESMTP id UAA07784; Fri, 6 Aug 1999 20:15:34 +1200 X-Authentication-Warning: loki.albatross.co.nz: psycho owned process doing -bs Date: Fri, 6 Aug 1999 20:15:33 +1200 (NZST) From: Keith Duthie To: =?iso-8859-1?Q?Christian_J=F6nsson_FOA_72?= cc: xxx , gcc@gcc.gnu.org Subject: Re: can't find libstdc++ In-Reply-To: <199908060657.IAA04109@arnljot.lin.foa.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 6 Aug 1999, Christian J=F6nsson FOA 72 wrote: > Hmm, that should not make a difference in this case, would it? If the=20 > ``make bootstrap'' succeeded *without* the --enable-shared, there would= =20 > have been a static libstdc++.a in a place that c++ ``run as linker'' woul= d=20 > have found it (libstdc++.a) , right? I've come across one or two things which failed to compile because they wanted shared libstdc++. I don't recall what they were, but it was probably my own fault anyway ;-) --=20 Understanding is a three edged sword. Do you *want* to get the point? http://www.albatross.co.nz/~psycho/ O- From gcc-return-8862-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 09:28:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5447 invoked by alias); 6 Aug 1999 09:28:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5429 invoked from network); 6 Aug 1999 09:28:28 -0000 Received: from rose.rz.uni-potsdam.de (root@141.89.70.104) by egcs.cygnus.com with SMTP; 6 Aug 1999 09:28:28 -0000 Received: from fox.bioinf.cs.uni-potsdam.de (rose@localhost [127.0.0.1]) by rose.rz.uni-potsdam.de (8.9.3/8.9.3) with ESMTP id LAA01184 for ; Fri, 6 Aug 1999 11:29:01 +0200 Message-ID: <37AAAADB.1756A841@fox.bioinf.cs.uni-potsdam.de> Date: Fri, 06 Aug 1999 11:28:59 +0200 From: Juergen Rose Organization: University of Potsdam X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: build status page Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I just installed gcc version 2.95 19990728 on a i686-pc-linux-gnulibc1 system. with best regards Juergen Rose From gcc-return-8863-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 11:51:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17958 invoked by alias); 6 Aug 1999 11:51:11 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17928 invoked from network); 6 Aug 1999 11:51:00 -0000 Received: from firewall.mindmaker.hu (194.152.134.8) by egcs.cygnus.com with SMTP; 6 Aug 1999 11:51:00 -0000 Received: (qmail 5801 invoked from network); 6 Aug 1999 13:50:16 -0000 Received: from garfield.inside (HELO mindmaker.hu) (192.168.1.125) by firewall.inside with SMTP; 6 Aug 1999 13:50:16 -0000 Message-ID: <37AACBF8.B82A9B@mindmaker.hu> Date: Fri, 06 Aug 1999 13:50:16 +0200 From: Levente Farkas Reply-To: lfarkas@mindmaker.hu Organization: Mindmaker Ltd. X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: hu,en MIME-Version: 1.0 Newsgroups: comp.lang.c++.moderated,comp.lang.c++ To: gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: mem_fun family (for_each, bind..) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, it's another strange program : ----------- #include #include #include class A { typedef std::vector vec; vec v; public: void f(double& d) const { ++d; } void g() { double d = 1; std::for_each(v.begin(), v.end(), std::bind2nd(std::mem_fun(&A::f), d)); } }; int main() { A a; a.g(); return 0; } ----------- I'm just wondering "is there anybody who realy try to use standard c++ ?". since I run into problems like this day after day. I'm not talking about that microsoft standard implemetation sucks all the day (like in the above ms forget to implement const member function (it can be corrected in ms's header file), but can't corrent template specialization for void since ms's compiler don't support it), but this simple example can't compile even on the latest egcs/gcc - 2.95! or am I wrong ? -- Levente From gcc-return-8864-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 14:09:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20702 invoked by alias); 6 Aug 1999 14:09:38 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20685 invoked from network); 6 Aug 1999 14:09:32 -0000 Received: from penguin-ext.wise.edt.ericsson.se (HELO penguin.wise.edt.ericsson.se) (194.237.142.110) by egcs.cygnus.com with SMTP; 6 Aug 1999 14:09:32 -0000 Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.44.44]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id QAA04701 for ; Fri, 6 Aug 1999 16:09:29 +0200 (MET DST) Received: from uabx01c259.uab.ericsson.se (uabx01c259 [134.138.227.19]) by ms.uab.ericsson.se (8.9.3/8.9.3/uab-1.37) with ESMTP id QAA05499 for ; Fri, 6 Aug 1999 16:09:28 +0200 (MET DST) Received: from uab.ericsson.se by uabx01c259.uab.ericsson.se (8.8.8+Sun/client-1.3) id QAA00389; Fri, 6 Aug 1999 16:09:27 +0200 (MET DST) Message-ID: <37AAEC97.FB204C80@uab.ericsson.se> Date: Fri, 06 Aug 1999 16:09:27 +0200 From: Aziz Shammas Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.51C-CCK-MCD [en] (X11; I; SunOS 5.5.1 sun4m) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Cross compiler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi I'm student from sweden and I loaded "GCC 2.95, gzip format, 12.3Meg." and I tried to build it but I never success. I tryied for three weeks ago and I had no chance to install it. I red almost manual about how to do but it isn't work. Do you have already builded cross compiler Sparc5 as HOST and PowerPC as target?? Do you know some one who tryied to install a cross compiler and sucessed?. Because it is very difficult to do it. I need a step by step manual which is tested before by some. I need any help you can offer to complite my Examination work. Thank you very much Aziz From gcc-return-8865-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 14:58:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25713 invoked by alias); 6 Aug 1999 14:58:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25545 invoked from network); 6 Aug 1999 14:58:06 -0000 Received: from mailgw.chips.ibm.com (192.91.197.8) by egcs.cygnus.com with SMTP; 6 Aug 1999 14:58:06 -0000 Received: from mailrelay.btv.ibm.com (mailrelay.btv.ibm.com [9.66.15.39]) by mailgw.chips.ibm.com (8.8.8/8.8.8) with ESMTP id KAA10216 for ; Fri, 6 Aug 1999 10:58:00 -0400 Received: from apache4.btv.ibm.com (apache4.btv.ibm.com [9.66.143.20]) by mailrelay.btv.ibm.com (8.8.8/8.8.8) with ESMTP id KAA117536 for ; Fri, 6 Aug 1999 10:57:38 -0400 Received: from apache4.btv.ibm.com (schuld@localhost) by apache4.btv.ibm.com (8.8.8/8.8.8) with ESMTP id KAA77444 for ; Fri, 6 Aug 1999 10:57:59 -0400 Message-Id: <199908061457.KAA77444@apache4.btv.ibm.com> X-Mailer: exmh version 2.0.3 3/23/99 To: gcc@gcc.gnu.org X-uri: http://www.chips.ibm.com/products/foundry/ X-Note-Format: RFC822 Subject: Build report for rs6000-ibm-aix4.3.2.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Aug 1999 10:57:59 -0400 From: "David W. Schuler" I have successfully compiled gcc version 2.95 19990728 (release) for rs6000-ibm-aix4.3.2.0. Counting all warnings, there are 3 warnings in stage3 of this bootstrap. Number of warnings per file: 2 cxxmain.c 1 ../../../gcc/gcc/f/com.c Number of warning types: 2 assignment discards qualifiers from pointer target type 1 unused parameter `???' From gcc-return-8866-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 15:19:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29273 invoked by alias); 6 Aug 1999 15:19:12 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29258 invoked from network); 6 Aug 1999 15:19:10 -0000 Received: from mail.pentek.com (HELO wiggum.pentek.com) (root@207.207.207.50) by egcs.cygnus.com with SMTP; 6 Aug 1999 15:19:10 -0000 Received: from pentek.com (charles-pc.pentek.com [192.168.200.52]) by wiggum.pentek.com (8.9.3/8.9.3) with ESMTP id LAA14418 for ; Fri, 6 Aug 1999 11:19:04 -0400 Message-ID: <37AAFD47.FA9030F2@pentek.com> Date: Fri, 06 Aug 1999 11:20:39 -0400 From: Charles Krug Organization: Pentek Corporation X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Has anyone built gcc-2.95 as a cross for TI c3x/c4x targets? References: <199908061457.KAA77444@apache4.btv.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello List: Has anyone built gcc-2.95 as a cross-compiler to TI c3x/c4x targets? Michael Hayes website seemed to say that 2.95 was going to include 'c3x/c4x targets. Has this been done yet? Has anyone built it? Thanx Charles From gcc-return-8867-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 15:46:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1180 invoked by alias); 6 Aug 1999 15:45:59 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1137 invoked from network); 6 Aug 1999 15:45:32 -0000 Received: from smtp.interlog.com (root@207.34.202.37) by egcs.cygnus.com with SMTP; 6 Aug 1999 15:45:32 -0000 Received: from crjnt2 (cj.interlog.com [199.212.157.174]) by smtp.interlog.com (8.9.1/8.9.1) with SMTP id LAA04772 for ; Fri, 6 Aug 1999 11:45:16 -0400 (EDT) Message-Id: <3.0.32.19990806114653.009798e0@mail.interlog.com> X-Sender: cj@mail.interlog.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 06 Aug 1999 11:46:58 -0400 To: egcs@egcs.cygnus.com From: "Christopher R. Jones" Subject: compile warning Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Building gcc-2.95 on Solaris 2.7, Intel using egcs-1.1.2 I get a number of errors similiar to: "..../toplev.c 1178 warning initialization from incompatible pointer type" is this something to be concerned about? Christopher R. Jones, P.Eng. 14 Oneida Avenue Toronto, Ontario M5J 2E3 Tel. 416 203-7465 Fax. 416 203-3044 Email cj@interlog.com From gcc-return-8868-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 16:14:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7995 invoked by alias); 6 Aug 1999 16:14:32 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7980 invoked from network); 6 Aug 1999 16:14:27 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 6 Aug 1999 16:14:27 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id KAA25122; Fri, 6 Aug 1999 10:12:31 -0600 X-Mailer: exmh version 2.0.2 To: John Wehle cc: gcc@gcc.gnu.org Subject: Re: CONST_CALL_P questions Reply-To: law@cygnus.com In-reply-to: Your message of Fri, 06 Aug 1999 00:16:31 EDT. <199908060416.AAA23620@jwlab.FEITH.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Aug 1999 10:12:30 -0600 Message-ID: <25119.933955950@upchuck.cygnus.com> From: Jeffrey A Law In message <199908060416.AAA23620@jwlab.FEITH.COM>you write: > 1) What's an example declaration and usage of a const call function? > I've been trying unsuccessfully to produce a sample which shows > up in a RTL dump. I would expect any of the intrinsic math functions to show up with CONST_CALL_P -- mulsi3, muldi3, addsi3, adddi3, etc etc. You should also be able to construct one using an attribute. > 2) If the INSN has CONST_CALL_P set then does that mean the call > has no possible side effects (not even in the parameters passed > to the call)? For example the parameters don't have PRE_DEC register > notes, volatile memory references, etc. and that the function doesn't > write to memory, modify global registers, reference volatile memory, > etc. This is covered in the manual. A "const" function is a pure function -- it evaluates its operands and produces a result based solely on those operands. It is not supposed to read/write memory (except for its own local stack space), modify global memory, etc. It can clobber its input parameters if they are passed in registers. It's not clear if it is allowed to clobber them if they are on the stack. Basically think of a constant call as allowing two calls with identical operands to be CSE'd since (in theory) the two calls should produce the same result since they have the same inputs. jeff From gcc-return-8869-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 16:41:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10610 invoked by alias); 6 Aug 1999 16:41:24 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10582 invoked from network); 6 Aug 1999 16:40:56 -0000 Received: from barbar.esat.kuleuven.ac.be (root@134.58.56.153) by egcs.cygnus.com with SMTP; 6 Aug 1999 16:40:56 -0000 Received: from coulomb.esat.kuleuven.ac.be (coulomb.esat.kuleuven.ac.be [134.58.189.131]) by barbar (version 8.8.5) for with ESMTP id SAA06953; Fri, 6 Aug 1999 18:40:44 +0200 (METDST) Organization: ESAT, K.U.Leuven, Belgium Received: by coulomb.esat.kuleuven.ac.be (8.8.8/1.1.22.3/21Jul99-0312PM) id SAA0000005014; Fri, 6 Aug 1999 18:40:43 +0200 (MET DST) X-Authentication-Warning: coulomb.esat.kuleuven.ac.be: deknuydt set sender to Bert.Deknuydt@esat.kuleuven.ac.be using -f From: AlBert DeKnuydt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14251.4104.463543.867093@gargle.gargle.HOWL> Date: Fri, 6 Aug 1999 18:40:40 +0200 (MET DST) To: gcc@gcc.gnu.org Subject: Build reports X-Mailer: VM 6.74 under Emacs 20.4.1 Hello, I have successful build reports on the following targets not yet in the list: alpha-dec-osf4.0f mips-dec-ultrix4.4 sparc-unknown-linux-gnu Greetings, B. -- -------------- eMail Bert.Deknuydt@esat.kuleuven.ac.be --------------- B.DeKnuydt, PSI-KULeuven Tel. +32-16-321880 K. Mercierlaan 94 /| | || B-3001 Heverlee Leuven _,_)| 4_|_|| FLANDERS, BELGIUM / . Fax. +32-16-321986 -------------- http://www.esat.kuleuven.ac.be/~deknuydt -------------- Surely Allah is with the patient. Qur'An, Sura 2, Verse 153 From gcc-return-8870-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 16:44:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11096 invoked by alias); 6 Aug 1999 16:44:28 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11023 invoked from network); 6 Aug 1999 16:44:00 -0000 Received: from remote1.oarcorp.com (HELO oar3remote.oarcorp.com) (208.166.120.97) by egcs.cygnus.com with SMTP; 6 Aug 1999 16:44:00 -0000 Received: from localhost (joel@localhost) by oar3remote.oarcorp.com (8.8.7/8.8.7) with ESMTP id LAA28683 for ; Fri, 6 Aug 1999 11:46:11 -0500 Date: Fri, 6 Aug 1999 11:46:11 -0500 (CDT) From: X-Sender: joel@oar3remote To: egcs@sourceware.cygnus.com Subject: gcc 2.95 RTEMS patch Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1496293000-453236816-933957971=:27834" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1496293000-453236816-933957971=:27834 Content-Type: TEXT/PLAIN; charset=US-ASCII The attached file is the RTEMS patch for gcc 2.95. It includes two patches that are already on the gcc 2.95.1 release branch: + an m68k CPU32 stack problem (Jeff?) + an sh build problem (J"orn Rennecke ) The general description of this patch is that it it moves most of the RTEMS targets to elf, renames the previous CPU-rtems target to something like CPU-rtemscoff or CPU-rtemsaout, and generally improves RTEMS support for C++ The ChangeLog changes are also included in the attached patch. The patch itself is about 800 lines. configure will have to be regenerated after applying this. That part of the diff was 1500 lines so I left it out. + Wed Jul 28 09:14:33 CDT 1999 Joel Sherrill + + * configure.in (m68k-*-rtemscoff*): Added. + * configure.in (mips64orion-*-rtems*): Converted to ELF. + * configure.in (sparc-*-rtemsaout*): Added as alias for old + sparc-rtems configuration. + * configure.in (sparc-*-rtemself*): Added. + * configure.in (sparc-*-rtems*): Now ELF not a.out. + * config/i386/rtems.h: Added comment. + * config/sparc/rtemself.h: New file. + + Tue Jul 13 20:57:02 1999 Charles-Antoine Gauthier + + * configure.in (m68k-rtemself): Added. + * config/elfos.h: Added ifndef wrapper for DWARF2_DEBUGGING_INFO + and DWARF_DEBUGGING_INFO. + * config/m68k/crti.s: New file. + * config/m68k/crtn.s: New file. + * config/m68k/t-crtstuff: New file. + * config/m68k/rtemself.h: New file. + + Fri May 14 09:28:07 CDT 1999 Rosimildo DaSilva + + * configure.in (i[[34567]]86-*-rtemself*): Now uses crtstuff for + global ctor/dtor and C++ exception handling. + * config/i386/rtemself.h: Now uses crtstuff (crti.o + crtbegin.o) + for STARTFILE_SPEC and crtstuff (crtend.o + crtn.o) for + ENDFILE_SPEC. + * config/i386/t-rtems-i386: New File. + --joel Joel Sherrill, Ph.D. Director of Research & Development joel@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 ---1496293000-453236816-933957971=:27834 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=j Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=j ZGlmZiAtTiAtUCAtciAtYyAvdXNyMS9ydGVtcy93b3JrL29yaWdpbmFsL2dj Yy0yLjk1L2djYy9DaGFuZ2VMb2cgZ2NjLTIuOTUvZ2NjL0NoYW5nZUxvZw0K KioqIC91c3IxL3J0ZW1zL3dvcmsvb3JpZ2luYWwvZ2NjLTIuOTUvZ2NjL0No YW5nZUxvZwlUaHUgSnVsIDI5IDA0OjQxOjE3IDE5OTkNCi0tLSBnY2MtMi45 NS9nY2MvQ2hhbmdlTG9nCVR1ZSBBdWcgIDMgMDg6MjA6MTYgMTk5OQ0KKioq KioqKioqKioqKioqDQoqKiogMSwzICoqKioNCi0tLSAxLDQzIC0tLS0NCisg RnJpIEp1biAgNCAwMzoyMDo0MCAxOTk5ICBKIm9ybiBSZW5uZWNrZSA8YW15 bGFhckBjeWdudXMuY28udWs+DQorIAkqIHNoLmMgKGZpeHVwX2FkZHJfZGlm Zl92ZWNzKTogRW1pdCBicmFmIHJlZmVyZW5jZSBsYWJlbC4NCisgCSAgKGJy YWZfbGFiZWxfcmVmX29wZXJhbmQpOiBEZWxldGUuDQorIAkqIHNoLmggKFBS RURJQ0FURV9DT0RFUyk6IFJlbW92ZSBicmFmX2xhYmVsX3JlZl9vcGVyYW5k Lg0KKyAJKiBzaC5tZCAoY2FzZXNpX2p1bXBfMik6IE9wZXJhbmQxIGlzIG5v dyB0aGUgaW5zaWRlIG9mIGENCisgCSAgbGFiZWxfcmVmLCBhbmQgaGFzIG5v IHByZWRpY2F0ZS4NCisgCSAgVGhlIHBhdHRlbiBoYXMgYSBwcmVkaWNhdGUg dG8gZ3VhcmQgYWdhaW5zdCBpbnZhbGlkIHN1YnN0aXR1dGlvbnMuDQorIAkg IChkdW1teV9qdW1wKTogRGVsZXRlLg0KKyAJICAoY2FzZXNpKTogVXBkYXRl IHVzZSBvZiBjYXNlc2lfanVtcF8yLg0KKyANCisgV2VkIEp1bCAyOCAwOTox NDozMyBDRFQgMTk5OSAgSm9lbCBTaGVycmlsbCA8am9lbEBPQVJjb3JwLmNv bT4NCisgDQorIAkqIGNvbmZpZ3VyZS5pbiAobTY4ay0qLXJ0ZW1zY29mZiop OiBBZGRlZC4NCisgCSogY29uZmlndXJlLmluIChtaXBzNjRvcmlvbi0qLXJ0 ZW1zKik6IENvbnZlcnRlZCB0byBFTEYuDQorIAkqIGNvbmZpZ3VyZS5pbiAo c3BhcmMtKi1ydGVtc2FvdXQqKTogQWRkZWQgYXMgYWxpYXMgZm9yIG9sZA0K KyAJICBzcGFyYy1ydGVtcyBjb25maWd1cmF0aW9uLg0KKyAJKiBjb25maWd1 cmUuaW4gKHNwYXJjLSotcnRlbXNlbGYqKTogQWRkZWQuDQorIAkqIGNvbmZp Z3VyZS5pbiAoc3BhcmMtKi1ydGVtcyopOiBOb3cgRUxGIG5vdCBhLm91dC4N CisgCSogY29uZmlnL2kzODYvcnRlbXMuaDogQWRkZWQgY29tbWVudC4NCisg CSogY29uZmlnL3NwYXJjL3J0ZW1zZWxmLmg6IE5ldyBmaWxlLg0KKyANCisg VHVlIEp1bCAxMyAyMDo1NzowMiAxOTk5ICBDaGFybGVzLUFudG9pbmUgR2F1 dGhpZXIgPGNoYXJsZXMuZ2F1dGhpZXJAaWl0Lm5yYy5jYT4NCisgDQorIAkq IGNvbmZpZ3VyZS5pbiAobTY4ay1ydGVtc2VsZik6IEFkZGVkLg0KKyAJKiBj b25maWcvZWxmb3MuaDogQWRkZWQgaWZuZGVmIHdyYXBwZXIgZm9yIERXQVJG Ml9ERUJVR0dJTkdfSU5GTw0KKyAJICBhbmQgRFdBUkZfREVCVUdHSU5HX0lO Rk8uDQorIAkqIGNvbmZpZy9tNjhrL2NydGkuczogTmV3IGZpbGUuDQorIAkq IGNvbmZpZy9tNjhrL2NydG4uczogTmV3IGZpbGUuDQorIAkqIGNvbmZpZy9t NjhrL3QtY3J0c3R1ZmY6IE5ldyBmaWxlLg0KKyAJKiBjb25maWcvbTY4ay9y dGVtc2VsZi5oOiBOZXcgZmlsZS4NCisgDQorIEZyaSBNYXkgMTQgMDk6Mjg6 MDcgQ0RUIDE5OTkgIFJvc2ltaWxkbyBEYVNpbHZhIDxyZGFzaWx2YUBjb25u ZWN0dGVsLmNvbT4NCisgDQorICAgICAgICogY29uZmlndXJlLmluIChpW1sz NDU2N11dODYtKi1ydGVtc2VsZiopOiBOb3cgdXNlcyBjcnRzdHVmZiBmb3IN CisgICAgICAgICBnbG9iYWwgY3Rvci9kdG9yIGFuZCBDKysgZXhjZXB0aW9u IGhhbmRsaW5nLg0KKyAgICAgICAqIGNvbmZpZy9pMzg2L3J0ZW1zZWxmLmg6 IE5vdyB1c2VzIGNydHN0dWZmIChjcnRpLm8gKyBjcnRiZWdpbi5vKQ0KKyAg ICAgICAgIGZvciBTVEFSVEZJTEVfU1BFQyBhbmQgY3J0c3R1ZmYgKGNydGVu ZC5vICsgY3J0bi5vKSBmb3INCisgICAgICAgICBFTkRGSUxFX1NQRUMuDQor ICAgICAgICogY29uZmlnL2kzODYvdC1ydGVtcy1pMzg2OiBOZXcgRmlsZS4N CisgDQogIFdlZCBKdWwgMjggMjE6Mzk6MzEgUERUIDE5OTkgSmVmZiBMYXcg IChsYXdAY3lnbnVzLmNvbSkNCiAgDQogIAkqIGdjYy0yLjk1IFJlbGVhc2Vk Lg0KZGlmZiAtTiAtUCAtciAtYyAvdXNyMS9ydGVtcy93b3JrL29yaWdpbmFs L2djYy0yLjk1L2djYy9jb25maWcvZWxmb3MuaCBnY2MtMi45NS9nY2MvY29u ZmlnL2VsZm9zLmgNCioqKiAvdXNyMS9ydGVtcy93b3JrL29yaWdpbmFsL2dj Yy0yLjk1L2djYy9jb25maWcvZWxmb3MuaAlGcmkgTWFyIDI2IDA0OjQ1OjI2 IDE5OTkNCi0tLSBnY2MtMi45NS9nY2MvY29uZmlnL2VsZm9zLmgJTW9uIEF1 ZyAgMiAxMjoyMjozNyAxOTk5DQoqKioqKioqKioqKioqKioNCioqKiA2OSw3 OSAqKioqDQogIA0KICAvKiBTeXN0ZW0gViBSZWxlYXNlIDQgdXNlcyBEV0FS RiBkZWJ1Z2dpbmcgaW5mby4gICovDQogIA0KISAjZGVmaW5lIERXQVJGX0RF QlVHR0lOR19JTkZPDQogIA0KICAvKiBBbGwgRUxGIHRhcmdldHMgY2FuIHN1 cHBvcnQgRFdBUkYtMi4gICovDQogIA0KISAjZGVmaW5lIERXQVJGMl9ERUJV R0dJTkdfSU5GTw0KICANCiAgLyogQWxzbyBhbGxvdyB0aGVtIHRvIHN1cHBv cnQgU1RBQlMgZGVidWdnaW5nLiAgKi8NCiAgDQotLS0gNjksODMgLS0tLQ0K ICANCiAgLyogU3lzdGVtIFYgUmVsZWFzZSA0IHVzZXMgRFdBUkYgZGVidWdn aW5nIGluZm8uICAqLw0KICANCiEgI2lmbmRlZiBEV0FSRl9ERUJVR0dJTkdf SU5GTw0KISAjZGVmaW5lIERXQVJGX0RFQlVHR0lOR19JTkZPIDENCiEgI2Vu ZGlmDQogIA0KICAvKiBBbGwgRUxGIHRhcmdldHMgY2FuIHN1cHBvcnQgRFdB UkYtMi4gICovDQogIA0KISAjaWZuZGVmIERXQVJGMl9ERUJVR0dJTkdfSU5G Tw0KISAjZGVmaW5lIERXQVJGMl9ERUJVR0dJTkdfSU5GTyAxDQohICNlbmRp Zg0KICANCiAgLyogQWxzbyBhbGxvdyB0aGVtIHRvIHN1cHBvcnQgU1RBQlMg ZGVidWdnaW5nLiAgKi8NCiAgDQpkaWZmIC1OIC1QIC1yIC1jIC91c3IxL3J0 ZW1zL3dvcmsvb3JpZ2luYWwvZ2NjLTIuOTUvZ2NjL2NvbmZpZy9pMzg2L3J0 ZW1zLmggZ2NjLTIuOTUvZ2NjL2NvbmZpZy9pMzg2L3J0ZW1zLmgNCioqKiAv dXNyMS9ydGVtcy93b3JrL29yaWdpbmFsL2djYy0yLjk1L2djYy9jb25maWcv aTM4Ni9ydGVtcy5oCVdlZCBEZWMgMTYgMTU6MDM6NTYgMTk5OA0KLS0tIGdj Yy0yLjk1L2djYy9jb25maWcvaTM4Ni9ydGVtcy5oCU1vbiBBdWcgIDIgMTI6 MjI6MzcgMTk5OQ0KKioqKioqKioqKioqKioqDQoqKiogMzIsMzQgKioqKg0K LS0tIDMyLDM1IC0tLS0NCiAgI2RlZmluZSBUQVJHRVRfTUVNX0ZVTkNUSU9O Uw0KICAjZW5kaWYNCiAgDQorIC8qIGVuZCBvZiBpMzg2L3J0ZW1zLmggKi8N CmRpZmYgLU4gLVAgLXIgLWMgL3VzcjEvcnRlbXMvd29yay9vcmlnaW5hbC9n Y2MtMi45NS9nY2MvY29uZmlnL2kzODYvcnRlbXNlbGYuaCBnY2MtMi45NS9n Y2MvY29uZmlnL2kzODYvcnRlbXNlbGYuaA0KKioqIC91c3IxL3J0ZW1zL3dv cmsvb3JpZ2luYWwvZ2NjLTIuOTUvZ2NjL2NvbmZpZy9pMzg2L3J0ZW1zZWxm LmgJV2VkIERlYyAxNiAxNTowMzo1NyAxOTk4DQotLS0gZ2NjLTIuOTUvZ2Nj L2NvbmZpZy9pMzg2L3J0ZW1zZWxmLmgJTW9uIEF1ZyAgMiAxMjoyMjozNyAx OTk5DQoqKioqKioqKioqKioqKioNCioqKiAxNjMsMTY5ICoqKioNCiAgICBh c21fb3V0cHV0X2FsaWduZWRfYnNzIChGSUxFLCBERUNMLCBOQU1FLCBTSVpF LCBBTElHTikNCiAgDQogICN1bmRlZiBTVEFSVEZJTEVfU1BFQw0KISAjZGVm aW5lIFNUQVJURklMRV9TUEVDICAiY3J0MC5vJXMiDQogIA0KICAjdW5kZWYg RU5ERklMRV9TUEVDDQogICAgICAgDQotLS0gMTYzLDE3MSAtLS0tDQogICAg YXNtX291dHB1dF9hbGlnbmVkX2JzcyAoRklMRSwgREVDTCwgTkFNRSwgU0la RSwgQUxJR04pDQogIA0KICAjdW5kZWYgU1RBUlRGSUxFX1NQRUMNCiEgI2Rl ZmluZSBTVEFSVEZJTEVfU1BFQyAiY3J0MC5vJXMgY3J0aS5vJXMgY3J0YmVn aW4ubyVzIg0KICANCiAgI3VuZGVmIEVOREZJTEVfU1BFQw0KKyAjZGVmaW5l IEVOREZJTEVfU1BFQyAgICJjcnRlbmQubyVzIGNydG4ubyVzIg0KKyANCiAg ICAgICANCmRpZmYgLU4gLVAgLXIgLWMgL3VzcjEvcnRlbXMvd29yay9vcmln aW5hbC9nY2MtMi45NS9nY2MvY29uZmlnL2kzODYvdC1ydGVtcy1pMzg2IGdj Yy0yLjk1L2djYy9jb25maWcvaTM4Ni90LXJ0ZW1zLWkzODYNCioqKiAvdXNy MS9ydGVtcy93b3JrL29yaWdpbmFsL2djYy0yLjk1L2djYy9jb25maWcvaTM4 Ni90LXJ0ZW1zLWkzODYJV2VkIERlYyAzMSAxODowMDowMCAxOTY5DQotLS0g Z2NjLTIuOTUvZ2NjL2NvbmZpZy9pMzg2L3QtcnRlbXMtaTM4NglNb24gQXVn ICAyIDEyOjIyOjM3IDE5OTkNCioqKioqKioqKioqKioqKg0KKioqIDAgKioq Kg0KLS0tIDEsMTcgLS0tLQ0KKyAjDQorICMgVGhpcyBmaWxlIHdhcyBiYXNl ZCBvbiB0LXNvbDIgLSB4NjggU29sYXJpcyBpbXBsZW1lbnRhdGlvbi4gQWN0 dWFsbHksDQorICMgdGhlIHNvdXJjZSBjb2RlIHRvIGNyZWF0ZSBjcnRpLm8g YW5mIGNydG4ubyBhcmUgZXhhY3RseSB0aGUgc2FtZSANCisgIyBhcyB0aGUg b25lcyBmb3IgU29sYXJpcy4gTGF0ZXIsIHdlIG1pZ2h0IHdhbnQgdG8gaGF2 ZSBhIFJURU1TJ3MgDQorICMgdmVyc2lvbiBvZiB0aGVzZSBmaWxlcy4NCisg Iw0KKyANCisgTElCR0NDMSA9IA0KKyBDUk9TU19MSUJHQ0MxID0gDQorIA0K KyBjcnRpLm86ICQoc3JjZGlyKS9jb25maWcvaTM4Ni9zb2wyLWNpLmFzbSAk KEdDQ19QQVNTRVMpDQorIAlzZWQgLWUgJy9eIS9kJyA8JChzcmNkaXIpL2Nv bmZpZy9pMzg2L3NvbDItY2kuYXNtID5jcnRpLnMNCisgCSQoR0NDX0ZPUl9U QVJHRVQpIC1jIC1vIGNydGkubyBjcnRpLnMNCisgY3J0bi5vOiAkKHNyY2Rp cikvY29uZmlnL2kzODYvc29sMi1jbi5hc20gJChHQ0NfUEFTU0VTKQ0KKyAJ c2VkIC1lICcvXiEvZCcgPCQoc3JjZGlyKS9jb25maWcvaTM4Ni9zb2wyLWNu LmFzbSA+Y3J0bi5zDQorIAkkKEdDQ19GT1JfVEFSR0VUKSAtYyAtbyBjcnRu Lm8gY3J0bi5zDQorIA0KZGlmZiAtTiAtUCAtciAtYyAvdXNyMS9ydGVtcy93 b3JrL29yaWdpbmFsL2djYy0yLjk1L2djYy9jb25maWcvbTY4ay9jcnRpLnMg Z2NjLTIuOTUvZ2NjL2NvbmZpZy9tNjhrL2NydGkucw0KKioqIC91c3IxL3J0 ZW1zL3dvcmsvb3JpZ2luYWwvZ2NjLTIuOTUvZ2NjL2NvbmZpZy9tNjhrL2Ny dGkucwlXZWQgRGVjIDMxIDE4OjAwOjAwIDE5NjkNCi0tLSBnY2MtMi45NS9n Y2MvY29uZmlnL202OGsvY3J0aS5zCU1vbiBBdWcgIDIgMTI6MjI6MzcgMTk5 OQ0KKioqKioqKioqKioqKioqDQoqKiogMCAqKioqDQotLS0gMSw0NyAtLS0t DQorIC8qIFNwZWNpYWxpemVkIGNvZGUgbmVlZGVkIHRvIHN1cHBvcnQgY29u c3RydWN0aW9uIGFuZCBkZXN0cnVjdGlvbiBvZg0KKyAgICBmaWxlLXNjb3Bl IG9iamVjdHMgaW4gQysrIGFuZCBKYXZhIGNvZGUsIGFuZCB0byBzdXBwb3J0 IGV4Y2VwdGlvbiBoYW5kbGluZy4NCisgICAgQ29weXJpZ2h0IChDKSAxOTk5 IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLg0KKyAgICBDb250cmli dXRlZCBieSBDaGFybGVzLUFudG9pbmUgR2F1dGhpZXIgKGNoYXJsZXMuZ2F1 dGhpZXJAaWl0Lm5yYy5jYSkuDQorIA0KKyBUaGlzIGZpbGUgaXMgcGFydCBv ZiBHTlUgQ0MuDQorIA0KKyBHTlUgQ0MgaXMgZnJlZSBzb2Z0d2FyZTsgeW91 IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQ0KKyBpdCB1bmRl ciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl IGFzIHB1Ymxpc2hlZCBieQ0KKyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0 aW9uOyBlaXRoZXIgdmVyc2lvbiAyLCBvciAoYXQgeW91ciBvcHRpb24pDQor IGFueSBsYXRlciB2ZXJzaW9uLg0KKyANCisgR05VIENDIGlzIGRpc3RyaWJ1 dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsDQorIGJ1 dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBs aWVkIHdhcnJhbnR5IG9mDQorIE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNT IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUNCisgR05VIEdl bmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4NCisgDQor IFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBH ZW5lcmFsIFB1YmxpYyBMaWNlbnNlDQorIGFsb25nIHdpdGggR05VIENDOyBz ZWUgdGhlIGZpbGUgQ09QWUlORy4gIElmIG5vdCwgd3JpdGUgdG8NCisgdGhl IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgNTkgVGVtcGxlIFBsYWNlIC0g U3VpdGUgMzMwLA0KKyBCb3N0b24sIE1BIDAyMTExLTEzMDcsIFVTQS4gICov DQorIA0KKyAvKiBBcyBhIHNwZWNpYWwgZXhjZXB0aW9uLCBpZiB5b3UgbGlu ayB0aGlzIGxpYnJhcnkgd2l0aCBmaWxlcw0KKyAgICBjb21waWxlZCB3aXRo IEdDQyB0byBwcm9kdWNlIGFuIGV4ZWN1dGFibGUsIHRoaXMgZG9lcyBub3Qg Y2F1c2UNCisgICAgdGhlIHJlc3VsdGluZyBleGVjdXRhYmxlIHRvIGJlIGNv dmVyZWQgYnkgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLg0KKyAg ICBUaGlzIGV4Y2VwdGlvbiBkb2VzIG5vdCBob3dldmVyIGludmFsaWRhdGUg YW55IG90aGVyIHJlYXNvbnMgd2h5DQorICAgIHRoZSBleGVjdXRhYmxlIGZp bGUgbWlnaHQgYmUgY292ZXJlZCBieSB0aGUgR05VIEdlbmVyYWwgUHVibGlj IExpY2Vuc2UuICAqLw0KKyANCisgLyoNCisgICogVGhpcyBmaWxlIGp1c3Qg c3VwcGxpZXMgZnVuY3Rpb24gcHJvbG9ndWVzIGZvciB0aGUgLmluaXQgYW5k IC5maW5pDQorICAqIHNlY3Rpb25zLiAgSXQgaXMgbGlua2VkIGluIGJlZm9y ZSBjcnRiZWdpbi5vLg0KKyAgKi8NCisgDQorIAkuZmlsZSAgICJjcnRpLm8i DQorIAkuaWRlbnQgICJHTlUgQyBjcnRpLm8iDQorIA0KKyAJLnNlY3Rpb24g LmluaXQNCisgCS5nbG9ibCAgX2luaXQNCisgCS50eXBlICAgX2luaXQsQGZ1 bmN0aW9uDQorIF9pbml0Og0KKyAJbGlua3cgJWZwLCMwDQorIA0KKyAJLnNl Y3Rpb24gLmZpbmkNCisgCS5nbG9ibCAgX2ZpbmkNCisgCS50eXBlICAgX2Zp bmksQGZ1bmN0aW9uDQorIF9maW5pOg0KKyAJbGlua3cgJWZwLCMwDQpkaWZm IC1OIC1QIC1yIC1jIC91c3IxL3J0ZW1zL3dvcmsvb3JpZ2luYWwvZ2NjLTIu OTUvZ2NjL2NvbmZpZy9tNjhrL2NydG4ucyBnY2MtMi45NS9nY2MvY29uZmln L202OGsvY3J0bi5zDQoqKiogL3VzcjEvcnRlbXMvd29yay9vcmlnaW5hbC9n Y2MtMi45NS9nY2MvY29uZmlnL202OGsvY3J0bi5zCVdlZCBEZWMgMzEgMTg6 MDA6MDAgMTk2OQ0KLS0tIGdjYy0yLjk1L2djYy9jb25maWcvbTY4ay9jcnRu LnMJTW9uIEF1ZyAgMiAxMjoyMjozNyAxOTk5DQoqKioqKioqKioqKioqKioN CioqKiAwICoqKioNCi0tLSAxLDQzIC0tLS0NCisgLyogU3BlY2lhbGl6ZWQg Y29kZSBuZWVkZWQgdG8gc3VwcG9ydCBjb25zdHJ1Y3Rpb24gYW5kIGRlc3Ry dWN0aW9uIG9mDQorICAgIGZpbGUtc2NvcGUgb2JqZWN0cyBpbiBDKysgYW5k IEphdmEgY29kZSwgYW5kIHRvIHN1cHBvcnQgZXhjZXB0aW9uIGhhbmRsaW5n Lg0KKyAgICBDb3B5cmlnaHQgKEMpIDE5OTkgRnJlZSBTb2Z0d2FyZSBGb3Vu ZGF0aW9uLCBJbmMuDQorICAgIENvbnRyaWJ1dGVkIGJ5IENoYXJsZXMtQW50 b2luZSBHYXV0aGllciAoY2hhcmxlcy5nYXV0aGllckBpaXQubnJjLmNhKS4N CisgDQorIFRoaXMgZmlsZSBpcyBwYXJ0IG9mIEdOVSBDQy4NCisgDQorIEdO VSBDQyBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBp dCBhbmQvb3IgbW9kaWZ5DQorIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUg R05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5DQor IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9u IDIsIG9yIChhdCB5b3VyIG9wdGlvbikNCisgYW55IGxhdGVyIHZlcnNpb24u DQorIA0KKyBHTlUgQ0MgaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhh dCBpdCB3aWxsIGJlIHVzZWZ1bCwNCisgYnV0IFdJVEhPVVQgQU5ZIFdBUlJB TlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YNCisg TUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQ VVJQT1NFLiAgU2VlIHRoZQ0KKyBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z ZSBmb3IgbW9yZSBkZXRhaWxzLg0KKyANCisgWW91IHNob3VsZCBoYXZlIHJl Y2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vu c2UNCisgYWxvbmcgd2l0aCBHTlUgQ0M7IHNlZSB0aGUgZmlsZSBDT1BZSU5H LiAgSWYgbm90LCB3cml0ZSB0bw0KKyB0aGUgRnJlZSBTb2Z0d2FyZSBGb3Vu ZGF0aW9uLCA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0ZSAzMzAsDQorIEJvc3Rv biwgTUEgMDIxMTEtMTMwNywgVVNBLiAgKi8NCisgDQorIC8qIEFzIGEgc3Bl Y2lhbCBleGNlcHRpb24sIGlmIHlvdSBsaW5rIHRoaXMgbGlicmFyeSB3aXRo IGZpbGVzDQorICAgIGNvbXBpbGVkIHdpdGggR0NDIHRvIHByb2R1Y2UgYW4g ZXhlY3V0YWJsZSwgdGhpcyBkb2VzIG5vdCBjYXVzZQ0KKyAgICB0aGUgcmVz dWx0aW5nIGV4ZWN1dGFibGUgdG8gYmUgY292ZXJlZCBieSB0aGUgR05VIEdl bmVyYWwgUHVibGljIExpY2Vuc2UuDQorICAgIFRoaXMgZXhjZXB0aW9uIGRv ZXMgbm90IGhvd2V2ZXIgaW52YWxpZGF0ZSBhbnkgb3RoZXIgcmVhc29ucyB3 aHkNCisgICAgdGhlIGV4ZWN1dGFibGUgZmlsZSBtaWdodCBiZSBjb3ZlcmVk IGJ5IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZS4gICovDQorIA0K KyAvKg0KKyAgKiBUaGlzIGZpbGUgc3VwcGxpZXMgZnVuY3Rpb24gZXBpbG9n dWVzIGZvciB0aGUgLmluaXQgYW5kIC5maW5pIHNlY3Rpb25zLg0KKyAgKiBJ dCBpcyBsaW5rZWQgaW4gYWZ0ZXIgYWxsIG90aGVyIGZpbGVzLg0KKyAgKi8N CisgDQorIAkuZmlsZSAgICJjcnRuLm8iDQorIAkuaWRlbnQgICJHTlUgQyBj cnRuLm8iDQorIA0KKyAJLnNlY3Rpb24gLmluaXQNCisgCXVubGsgJWZwDQor IAlydHMNCisgDQorIAkuc2VjdGlvbiAuZmluaQ0KKyAJdW5sayAlZnANCisg CXJ0cw0KZGlmZiAtTiAtUCAtciAtYyAvdXNyMS9ydGVtcy93b3JrL29yaWdp bmFsL2djYy0yLjk1L2djYy9jb25maWcvbTY4ay9tNjhrLmMgZ2NjLTIuOTUv Z2NjL2NvbmZpZy9tNjhrL202OGsuYw0KKioqIC91c3IxL3J0ZW1zL3dvcmsv b3JpZ2luYWwvZ2NjLTIuOTUvZ2NjL2NvbmZpZy9tNjhrL202OGsuYwlGcmkg SnVsIDE2IDAyOjQxOjMwIDE5OTkNCi0tLSBnY2MtMi45NS9nY2MvY29uZmln L202OGsvbTY4ay5jCU1vbiBBdWcgIDIgMTI6MjQ6MjYgMTk5OQ0KKioqKioq KioqKioqKioqDQoqKiogMjQyLDI1MSAqKioqDQogIAkgICAgICAvKiBhc21f ZnByaW50ZigpIGNhbm5vdCBoYW5kbGUgJS4gKi8NCiAgI2lmZGVmIE1PVE9S T0xBDQogIAkgICAgICBhc21fZnByaW50ZiAoc3RyZWFtLCAiXHRzdWJxLncg JTBJOCwlUnNwXG5cdHN1YnEudyAlMEklZCwlUnNwXG4iLA0KISAJCQkgICBm c2l6ZSArIDQpOw0KICAjZWxzZQ0KICAJICAgICAgYXNtX2ZwcmludGYgKHN0 cmVhbSwgIlx0c3VicXcgJTBJOCwlUnNwXG5cdHN1YnF3ICUwSSVkLCVSc3Bc biIsDQohIAkJCSAgIGZzaXplICsgNCk7DQogICNlbmRpZg0KICAJICAgIH0N CiAgCSAgZWxzZSANCi0tLSAyNDIsMjUxIC0tLS0NCiAgCSAgICAgIC8qIGFz bV9mcHJpbnRmKCkgY2Fubm90IGhhbmRsZSAlLiAqLw0KICAjaWZkZWYgTU9U T1JPTEENCiAgCSAgICAgIGFzbV9mcHJpbnRmIChzdHJlYW0sICJcdHN1YnEu dyAlMEk4LCVSc3Bcblx0c3VicS53ICUwSSVkLCVSc3BcbiIsDQohIAkJCSAg IGZzaXplIC0gNCk7DQogICNlbHNlDQogIAkgICAgICBhc21fZnByaW50ZiAo c3RyZWFtLCAiXHRzdWJxdyAlMEk4LCVSc3Bcblx0c3VicXcgJTBJJWQsJVJz cFxuIiwNCiEgCQkJICAgZnNpemUgLSA0KTsNCiAgI2VuZGlmDQogIAkgICAg fQ0KICAJICBlbHNlIA0KKioqKioqKioqKioqKioqDQoqKiogNzkwLDc5OSAq KioqDQogIAkgIC8qIGFzbV9mcHJpbnRmKCkgY2Fubm90IGhhbmRsZSAlLiAq Lw0KICAjaWZkZWYgTU9UT1JPTEENCiAgCSAgYXNtX2ZwcmludGYgKHN0cmVh bSwgIlx0YWRkcS53ICUwSTgsJVJzcFxuXHRhZGRxLncgJTBJJWQsJVJzcFxu IiwNCiEgCQkgICAgICAgZnNpemUgKyA0KTsNCiAgI2Vsc2UNCiAgCSAgYXNt X2ZwcmludGYgKHN0cmVhbSwgIlx0YWRkcXcgJTBJOCwlUnNwXG5cdGFkZHF3 ICUwSSVkLCVSc3BcbiIsDQohIAkJICAgICAgIGZzaXplICsgNCk7DQogICNl bmRpZg0KICAJfQ0KICAgICAgICBlbHNlDQotLS0gNzkwLDc5OSAtLS0tDQog IAkgIC8qIGFzbV9mcHJpbnRmKCkgY2Fubm90IGhhbmRsZSAlLiAqLw0KICAj aWZkZWYgTU9UT1JPTEENCiAgCSAgYXNtX2ZwcmludGYgKHN0cmVhbSwgIlx0 YWRkcS53ICUwSTgsJVJzcFxuXHRhZGRxLncgJTBJJWQsJVJzcFxuIiwNCiEg CQkgICAgICAgZnNpemUgLSA0KTsNCiAgI2Vsc2UNCiAgCSAgYXNtX2Zwcmlu dGYgKHN0cmVhbSwgIlx0YWRkcXcgJTBJOCwlUnNwXG5cdGFkZHF3ICUwSSVk LCVSc3BcbiIsDQohIAkJICAgICAgIGZzaXplIC0gNCk7DQogICNlbmRpZg0K ICAJfQ0KICAgICAgICBlbHNlDQpkaWZmIC1OIC1QIC1yIC1jIC91c3IxL3J0 ZW1zL3dvcmsvb3JpZ2luYWwvZ2NjLTIuOTUvZ2NjL2NvbmZpZy9tNjhrL3J0 ZW1zZWxmLmggZ2NjLTIuOTUvZ2NjL2NvbmZpZy9tNjhrL3J0ZW1zZWxmLmgN CioqKiAvdXNyMS9ydGVtcy93b3JrL29yaWdpbmFsL2djYy0yLjk1L2djYy9j b25maWcvbTY4ay9ydGVtc2VsZi5oCVdlZCBEZWMgMzEgMTg6MDA6MDAgMTk2 OQ0KLS0tIGdjYy0yLjk1L2djYy9jb25maWcvbTY4ay9ydGVtc2VsZi5oCU1v biBBdWcgIDIgMTI6MjI6MzcgMTk5OQ0KKioqKioqKioqKioqKioqDQoqKiog MCAqKioqDQotLS0gMSw2NyAtLS0tDQorIC8qIERlZmluaXRpb25zIGZvciBy dGVtcyB0YXJnZXRpbmcgYSBNb3Rvcm9sYSBtNjhrIHVzaW5nIGVsZi4NCisg ICAgQ29weXJpZ2h0IChDKSAxOTk5LCBOYXRpb25hbCBSZXNlYXJjaCBDb3Vu Y2lsIG9mIENhbmFkYS4NCisgICAgQ29udHJpYnV0ZWQgYnkgQ2hhcmxlcy1B bnRvaW5lIEdhdXRoaWVyIChjaGFybGVzLmdhdXRoaWVyQG5yYy5jYSkuDQor IA0KKyBUaGlzIGZpbGUgaXMgcGFydCBvZiBHTlUgQ0MuDQorIA0KKyBHTlUg Q0MgaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQg YW5kL29yIG1vZGlmeQ0KKyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdO VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQ0KKyB0 aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAy LCBvciAoYXQgeW91ciBvcHRpb24pDQorIGFueSBsYXRlciB2ZXJzaW9uLg0K KyANCisgR05VIENDIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQg aXQgd2lsbCBiZSB1c2VmdWwsDQorIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5U WTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mDQorIE1F UkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVS UE9TRS4gIFNlZSB0aGUNCisgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2Ug Zm9yIG1vcmUgZGV0YWlscy4NCisgDQorIFlvdSBzaG91bGQgaGF2ZSByZWNl aXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl DQorIGFsb25nIHdpdGggR05VIENDOyBzZWUgdGhlIGZpbGUgQ09QWUlORy4g IElmIG5vdCwgd3JpdGUgdG8NCisgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRh dGlvbiwgNTkgVGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLA0KKyBCb3N0b24s IE1BIDAyMTExLTEzMDcsIFVTQS4gICovDQorIA0KKyANCisgI2RlZmluZSBN T1RPUk9MQSAgICAgICAvKiBVc2UgTW90b3JvbGEgc3ludGF4IHJhdGhlciB0 aGFuIE1JVC4gICovDQorIA0KKyAjaW5jbHVkZSAibTY4ay9tNjgwMjAtZWxm LmgiDQorIA0KKyAvKiBTcGVjaWZ5IHByZWRlZmluZWQgc3ltYm9scyBpbiBw cmVwcm9jZXNzb3IuICAqLw0KKyANCisgI3VuZGVmIENQUF9QUkVERUZJTkVT DQorICNkZWZpbmUgQ1BQX1BSRURFRklORVMgIi1EbWM2ODAwMCAtRHJ0ZW1z IC1EX19ydGVtc19fIC1EX19FTEZfXyBcDQorICAgIC1Bc3lzdGVtKHJ0ZW1z KSAtQWNwdShtYzY4MDAwKSAtQWNwdShtNjhrKSAtQW1hY2hpbmUobTY4ayki DQorIA0KKyAvKiBHZW5lcmF0ZSBjYWxscyB0byBtZW1jcHksIG1lbWNtcCBh bmQgbWVtc2V0LiAgKi8NCisgI2lmbmRlZiBUQVJHRVRfTUVNX0ZVTkNUSU9O Uw0KKyAjZGVmaW5lIFRBUkdFVF9NRU1fRlVOQ1RJT05TDQorICNlbmRpZg0K KyANCisgLyoNCisgICogIEVhY2ggUlRFTVMgQlNQIHByb3ZpZGVzIGl0cyBv d24gY3J0MCBhbmQgbGlua2VyIHNjcmlwdC4gIFVuZm9ydHVuYXRlbHkNCisg ICogIHRoaXMgbWVhbnMgdGhhdCBjcnQwIGFuZCB0aGUgbGlua2VyIHNjcmlw dCBhcmUgbm90IGF2YWlsYWJsZSBhcw0KKyAgKiAgZWFjaCB0b29sIGlzIGNv bmZpZ3VyZWQuICBXaXRob3V0IGEgY3J0MCBhbmQgbGlua2VyIHNjcmlwdCwg bTY4ayBFTEYNCisgICogIHRhcmdldHMgZG8gbm90IHN1Y2Nlc3NmdWxseSBs aW5rICJjb25mdGVzdC5jIiBkdXJpbmcgdGhlIGNvbmZpZ3VyYXRpb24NCisg ICogIHByb2Nlc3MuICBSVEVNUyBzdXBwbGllcyBhIGNydDAuYyB0aGF0IHBy b3ZpZGVzIGFsbCB0aGUgc3ltYm9scyByZXF1aXJlZA0KKyAgKiAgdG8gc3Vj Y2Vzc2Z1bGx5IGxpbmsgYSBwcm9ncmFtLiAgVGhlIHJlc3VsdGluZyBwcm9n cmFtIHdpbGwgbm90IHJ1biANCisgICogIGJ1dCB0aGlzIGlzIGVub3VnaCB0 byBzYXRpc2Z5IHRoZSBhdXRvY29uZiBtYWNybyBBQ19QUk9HX0NDLg0KKyAg KiAgT3ZlcnJpZGUgU1RBUlRGSUxFX1NQRUMgdG8gdXNlIHRoZSBmYWtlIGNy dDAubyBzdXBwbGllZCBieSBydGVtcy4NCisgICovDQorICN1bmRlZiBTVEFS VEZJTEVfU1BFQw0KKyAjZGVmaW5lIFNUQVJURklMRV9TUEVDICJjcnQwLm8l cyINCisgDQorIC8qDQorICAqICBSZWRlZmluZSBJTklUX1NFQ1RJT05fQVNN X09QIGFuZCBGSU5JX1NFQ1RJT05fQVNNX09QLiBUaGlzIGlzIHRoZSBlYXNp ZXN0DQorICAqICB3YXkgdG8gcHJvY2VzcyBjb25zdHJ1Y3RvcnMsIGRlc3Ry dWN0b3JzLCBhbmQgdGhlIGV4Y2VwdGlvbiBmcmFtZQ0KKyAgKiAgaW5mb3Jt YXRpb24gYXQgc3RhcnR1cC4NCisgICovDQorICN1bmRlZiBJTklUX1NFQ1RJ T05fQVNNX09QDQorICNkZWZpbmUgSU5JVF9TRUNUSU9OX0FTTV9PUCAgICAi LnNlY3Rpb25cdC5pbml0Ig0KKyAjdW5kZWYgRklOSV9TRUNUSU9OX0FTTV9P UA0KKyAjZGVmaW5lIEZJTklfU0VDVElPTl9BU01fT1AgICAgIi5zZWN0aW9u XHQuZmluaSINCisgDQorICN1bmRlZiBFSF9GUkFNRV9TRUNUSU9OX0FTTV9P UA0KKyAjZGVmaW5lIEVIX0ZSQU1FX1NFQ1RJT05fQVNNX09QICAgICAgICAi LnNlY3Rpb25cdC5laF9mcmFtZSINCisgDQorIC8qIERvIEkgbmVlZCB0aGlz PyAqLw0KKyAjdW5kZWYgSU5WT0tFX19tYWluDQorIA0KKyANCmRpZmYgLU4g LVAgLXIgLWMgL3VzcjEvcnRlbXMvd29yay9vcmlnaW5hbC9nY2MtMi45NS9n Y2MvY29uZmlnL202OGsvdC1jcnRzdHVmZiBnY2MtMi45NS9nY2MvY29uZmln L202OGsvdC1jcnRzdHVmZg0KKioqIC91c3IxL3J0ZW1zL3dvcmsvb3JpZ2lu YWwvZ2NjLTIuOTUvZ2NjL2NvbmZpZy9tNjhrL3QtY3J0c3R1ZmYJV2VkIERl YyAzMSAxODowMDowMCAxOTY5DQotLS0gZ2NjLTIuOTUvZ2NjL2NvbmZpZy9t NjhrL3QtY3J0c3R1ZmYJTW9uIEF1ZyAgMiAxMjoyMjozNyAxOTk5DQoqKioq KioqKioqKioqKioNCioqKiAwICoqKioNCi0tLSAxLDExIC0tLS0NCisgIyBm cm9tIC4uL3Qtc3ZyNA0KKyBFWFRSQV9QQVJUUz1jcnRiZWdpbi5vIGNydGVu ZC5vIGNydGkubyBjcnRuLm8NCisgDQorICMgQWRkIGZsYWdzIGhlcmUgYXMg cmVxdWlyZWQuDQorIENSVFNUVUZGX1RfQ0ZMQUdTID0NCisgDQorICMgQXNz ZW1ibGUgc3RhcnR1cCBmaWxlcy4NCisgY3J0aS5vOiAkKHNyY2RpcikvY29u ZmlnL202OGsvY3J0aS5zICQoR0NDX1BBU1NFUykNCisgCSQoR0NDX0ZPUl9U QVJHRVQpIC1jIC1vIGNydGkubyAkKHNyY2RpcikvY29uZmlnL202OGsvY3J0 aS5zDQorIGNydG4ubzogJChzcmNkaXIpL2NvbmZpZy9tNjhrL2NydG4ucyAk KEdDQ19QQVNTRVMpDQorIAkkKEdDQ19GT1JfVEFSR0VUKSAtYyAtbyBjcnRu Lm8gJChzcmNkaXIpL2NvbmZpZy9tNjhrL2NydG4ucw0KZGlmZiAtTiAtUCAt ciAtYyAvdXNyMS9ydGVtcy93b3JrL29yaWdpbmFsL2djYy0yLjk1L2djYy9j b25maWcvc2gvc2guYyBnY2MtMi45NS9nY2MvY29uZmlnL3NoL3NoLmMNCioq KiAvdXNyMS9ydGVtcy93b3JrL29yaWdpbmFsL2djYy0yLjk1L2djYy9jb25m aWcvc2gvc2guYwlXZWQgTWFyIDEwIDA1OjA3OjMwIDE5OTkNCi0tLSBnY2Mt Mi45NS9nY2MvY29uZmlnL3NoL3NoLmMJVHVlIEF1ZyAgMyAwODoxOToxNyAx OTk5DQoqKioqKioqKioqKioqKioNCioqKiAyNjQxLDI2NDcgKioqKg0KICAN CiAgICBmb3IgKGluc24gPSBmaXJzdDsgaW5zbjsgaW5zbiA9IE5FWFRfSU5T TiAoaW5zbikpDQogICAgICB7DQohICAgICAgIHJ0eCB2ZWNfbGFiLCBwYXQs IHByZXYsIHByZXZwYXQsIHg7DQogIA0KICAgICAgICBpZiAoR0VUX0NPREUg KGluc24pICE9IEpVTVBfSU5TTg0KICAJICB8fCBHRVRfQ09ERSAoUEFUVEVS TiAoaW5zbikpICE9IEFERFJfRElGRl9WRUMpDQotLS0gMjY0MSwyNjQ3IC0t LS0NCiAgDQogICAgZm9yIChpbnNuID0gZmlyc3Q7IGluc247IGluc24gPSBO RVhUX0lOU04gKGluc24pKQ0KICAgICAgew0KISAgICAgICBydHggdmVjX2xh YiwgcGF0LCBwcmV2LCBwcmV2cGF0LCB4LCBicmFmX2xhYmVsOw0KICANCiAg ICAgICAgaWYgKEdFVF9DT0RFIChpbnNuKSAhPSBKVU1QX0lOU04NCiAgCSAg fHwgR0VUX0NPREUgKFBBVFRFUk4gKGluc24pKSAhPSBBRERSX0RJRkZfVkVD KQ0KKioqKioqKioqKioqKioqDQoqKiogMjY2NCwyNjczICoqKioNCiAgCSAg aWYgKEdFVF9DT0RFICh4KSA9PSBMQUJFTF9SRUYgJiYgWEVYUCAoeCwgMCkg PT0gdmVjX2xhYikNCiAgCSAgICBicmVhazsNCiAgCX0NCiAgICAgICAgLyog Rml4IHVwIHRoZSBBRERSX0RJRl9WRUMgdG8gYmUgcmVsYXRpdmUNCiAgCSB0 byB0aGUgcmVmZXJlbmNlIGFkZHJlc3Mgb2YgdGhlIGJyYWYuICAqLw0KISAg ICAgICBYRVhQIChYRVhQIChwYXQsIDApLCAwKQ0KISAJPSBYRVhQIChYRVhQ IChTRVRfU1JDIChYVkVDRVhQIChwcmV2cGF0LCAwLCAwKSksIDEpLCAwKTsN CiAgICAgIH0NCiAgfQ0KICANCi0tLSAyNjY0LDI2NzggLS0tLQ0KICAJICBp ZiAoR0VUX0NPREUgKHgpID09IExBQkVMX1JFRiAmJiBYRVhQICh4LCAwKSA9 PSB2ZWNfbGFiKQ0KICAJICAgIGJyZWFrOw0KICAJfQ0KKyANCisgICAgICAg LyogRW1pdCB0aGUgcmVmZXJlbmNlIGxhYmVsIG9mIHRoZSBicmFmIHdoZXJl IGl0IGJlbG9uZ3MsIHJpZ2h0IGFmdGVyDQorIAkgdGhlIGNhc2VzaV9qdW1w XzIgKGkuZS4gYnJhZikuICAqLw0KKyAgICAgICBicmFmX2xhYmVsID0gWEVY UCAoWEVYUCAoU0VUX1NSQyAoWFZFQ0VYUCAocHJldnBhdCwgMCwgMCkpLCAx KSwgMCk7DQorICAgICAgIGVtaXRfbGFiZWxfYWZ0ZXIgKGJyYWZfbGFiZWws IHByZXYpOw0KKyANCiAgICAgICAgLyogRml4IHVwIHRoZSBBRERSX0RJRl9W RUMgdG8gYmUgcmVsYXRpdmUNCiAgCSB0byB0aGUgcmVmZXJlbmNlIGFkZHJl c3Mgb2YgdGhlIGJyYWYuICAqLw0KISAgICAgICBYRVhQIChYRVhQIChwYXQs IDApLCAwKSA9IGJyYWZfbGFiZWw7DQogICAgICB9DQogIH0NCiAgDQoqKioq KioqKioqKioqKioNCioqKiA0MzAxLDQzMjkgKioqKg0KICANCiAgICBSRUFM X1ZBTFVFX0ZST01fQ09OU1RfRE9VQkxFIChyLCBvcCk7DQogICAgcmV0dXJu IFJFQUxfVkFMVUVTX0VRVUFMIChyLCBkY29uc3QxKTsNCi0gfQ0KLSANCi0g aW50DQotIGJyYWZfbGFiZWxfcmVmX29wZXJhbmQob3AsIG1vZGUpDQotICAg ICAgcnR4IG9wOw0KLSAgICAgIGVudW0gbWFjaGluZV9tb2RlIG1vZGU7DQot IHsNCi0gICBydHggcHJldjsNCi0gDQotICAgaWYgKEdFVF9DT0RFIChvcCkg IT0gTEFCRUxfUkVGKQ0KLSAgICAgcmV0dXJuIDA7DQotICAgcHJldiA9IHBy ZXZfcmVhbF9pbnNuIChYRVhQIChvcCwgMCkpOw0KLSAgIGlmIChHRVRfQ09E RSAocHJldikgIT0gSlVNUF9JTlNOKQ0KLSAgICAgcmV0dXJuIDA7DQotICAg cHJldiA9IFBBVFRFUk4gKHByZXYpOw0KLSAgIGlmIChHRVRfQ09ERSAocHJl dikgIT0gUEFSQUxMRUwgfHwgWFZFQ0xFTiAocHJldiwgMCkgIT0gMikNCi0g ICAgIHJldHVybiAwOw0KLSAgIHByZXYgPSBYVkVDRVhQIChwcmV2LCAwLCAw KTsNCi0gICBpZiAoR0VUX0NPREUgKHByZXYpICE9IFNFVCkNCi0gICAgIHJl dHVybiAwOw0KLSAgIHByZXYgPSBTRVRfU1JDIChwcmV2KTsNCi0gICBpZiAo R0VUX0NPREUgKHByZXYpICE9IFBMVVMgfHwgWEVYUCAocHJldiwgMSkgIT0g b3ApDQotICAgICByZXR1cm4gMDsNCiAgfQ0KICANCiAgaW50DQotLS0gNDMw Niw0MzExIC0tLS0NCmRpZmYgLU4gLVAgLXIgLWMgL3VzcjEvcnRlbXMvd29y ay9vcmlnaW5hbC9nY2MtMi45NS9nY2MvY29uZmlnL3NoL3NoLmggZ2NjLTIu OTUvZ2NjL2NvbmZpZy9zaC9zaC5oDQoqKiogL3VzcjEvcnRlbXMvd29yay9v cmlnaW5hbC9nY2MtMi45NS9nY2MvY29uZmlnL3NoL3NoLmgJRnJpIE1hciAg NSAwNToyODozMyAxOTk5DQotLS0gZ2NjLTIuOTUvZ2NjL2NvbmZpZy9zaC9z aC5oCVR1ZSBBdWcgIDMgMDg6MTk6MjMgMTk5OQ0KKioqKioqKioqKioqKioq DQoqKiogMjEyMCwyMTI2ICoqKioNCiAgICB7ImFyaXRoX3JlZ19vcGVyYW5k Iiwge1NVQlJFRywgUkVHfX0sCQkJCQlcDQogICAgeyJhcml0aF9yZWdfb3Jf MF9vcGVyYW5kIiwge1NVQlJFRywgUkVHLCBDT05TVF9JTlR9fSwJCQlcDQog ICAgeyJiaW5hcnlfZmxvYXRfb3BlcmF0b3IiLCB7UExVUywgTVVMVH19LAkJ CQlcDQotICAgeyJicmFmX2xhYmVsX3JlZl9vcGVyYW5kIiwge0xBQkVMX1JF Rn19LAkJCQlcDQogICAgeyJjb21tdXRhdGl2ZV9mbG9hdF9vcGVyYXRvciIs IHtQTFVTLCBNVUxUfX0sCQkJCVwNCiAgICB7ImZwX2FyaXRoX3JlZ19vcGVy YW5kIiwge1NVQlJFRywgUkVHfX0sCQkJCVwNCiAgICB7ImZwX2V4dGVuZGVk X29wZXJhbmQiLCB7U1VCUkVHLCBSRUcsIEZMT0FUX0VYVEVORH19LAkJCVwN Ci0tLSAyMTIwLDIxMjUgLS0tLQ0KZGlmZiAtTiAtUCAtciAtYyAvdXNyMS9y dGVtcy93b3JrL29yaWdpbmFsL2djYy0yLjk1L2djYy9jb25maWcvc2gvc2gu bWQgZ2NjLTIuOTUvZ2NjL2NvbmZpZy9zaC9zaC5tZA0KKioqIC91c3IxL3J0 ZW1zL3dvcmsvb3JpZ2luYWwvZ2NjLTIuOTUvZ2NjL2NvbmZpZy9zaC9zaC5t ZAlUdWUgQXByIDI3IDA3OjIzOjIwIDE5OTkNCi0tLSBnY2MtMi45NS9nY2Mv Y29uZmlnL3NoL3NoLm1kCVR1ZSBBdWcgIDMgMDg6MTk6MTkgMTk5OQ0KKioq KioqKioqKioqKioqDQoqKiogMzIwMywzMjIxICoqKioNCiAgOzsgRm9yIGFs bCBsYXRlciBwcm9jZXNzb3JzLg0KICAoZGVmaW5lX2luc24gImNhc2VzaV9q dW1wXzIiDQogICAgWyhzZXQgKHBjKSAocGx1czpTSSAobWF0Y2hfb3BlcmFu ZDpTSSAwICJyZWdpc3Rlcl9vcGVyYW5kIiAiciIpDQohIAkJICAgICAgKG1h dGNoX29wZXJhbmQgMSAiYnJhZl9sYWJlbF9yZWZfb3BlcmFuZCIgIiIpKSkN CiAgICAgKHVzZSAobGFiZWxfcmVmIChtYXRjaF9vcGVyYW5kIDIgIiIgIiIp KSldDQohICAgIiINCiAgICAiYnJhZgklMCUjIg0KICAgIFsoc2V0X2F0dHIg Im5lZWRzX2RlbGF5X3Nsb3QiICJ5ZXMiKQ0KICAgICAoc2V0X2F0dHIgInR5 cGUiICJqdW1wX2luZCIpXSkNCiAgDQotIChkZWZpbmVfaW5zbiAiZHVtbXlf anVtcCINCi0gICBbKHNldCAocGMpIChjb25zdF9pbnQgMCkpXQ0KLSAgICIi DQotICAgIiINCi0gICBbKHNldF9hdHRyICJsZW5ndGgiICIwIildKQ0KLSAN CiAgOzsgQ2FsbCBzdWJyb3V0aW5lIHJldHVybmluZyBhbnkgdHlwZS4NCiAg OzsgPz8/IFRoaXMgcHJvYmFibHkgZG9lc24ndCB3b3JrLg0KICANCi0tLSAz MjAzLDMyMTUgLS0tLQ0KICA7OyBGb3IgYWxsIGxhdGVyIHByb2Nlc3NvcnMu DQogIChkZWZpbmVfaW5zbiAiY2FzZXNpX2p1bXBfMiINCiAgICBbKHNldCAo cGMpIChwbHVzOlNJIChtYXRjaF9vcGVyYW5kOlNJIDAgInJlZ2lzdGVyX29w ZXJhbmQiICJyIikNCiEgCQkgICAgICAobGFiZWxfcmVmIChtYXRjaF9vcGVy YW5kIDEgIiIgIiIpKSkpDQogICAgICh1c2UgKGxhYmVsX3JlZiAobWF0Y2hf b3BlcmFuZCAyICIiICIiKSkpXQ0KISAgICIhIElOU05fVUlEIChvcGVyYW5k c1sxXSkgfHwgcHJldl9yZWFsX2luc24gKG9wZXJhbmRzWzFdKSA9PSBpbnNu Ig0KICAgICJicmFmCSUwJSMiDQogICAgWyhzZXRfYXR0ciAibmVlZHNfZGVs YXlfc2xvdCIgInllcyIpDQogICAgIChzZXRfYXR0ciAidHlwZSIgImp1bXBf aW5kIildKQ0KICANCiAgOzsgQ2FsbCBzdWJyb3V0aW5lIHJldHVybmluZyBh bnkgdHlwZS4NCiAgOzsgPz8/IFRoaXMgcHJvYmFibHkgZG9lc24ndCB3b3Jr Lg0KICANCioqKioqKioqKioqKioqKg0KKioqIDMzMDIsMzMyMSAqKioqDQog IAkJCSAgIHJlZykpOw0KICAgIGVtaXRfaW5zbiAoZ2VuX2Nhc2VzaV93b3Jr ZXJfMCAocmVnMiwgcmVnLCBvcGVyYW5kc1szXSkpOw0KICAgIGlmIChUQVJH RVRfU0gyKQ0KISAgICAgew0KISAgICAgICBydHggbGFiID0gZ2VuX2xhYmVs X3J0eCAoKTsNCiEgICAgICAgZW1pdF9qdW1wX2luc24gKGdlbl9jYXNlc2lf anVtcF8yIChyZWcyLA0KISAJCQkJCSBnZW5fcnR4IChMQUJFTF9SRUYsIFZP SURtb2RlLCBsYWIpLA0KISAJCQkJCSBvcGVyYW5kc1szXSkpOw0KISAgICAg ICBlbWl0X2xhYmVsIChsYWIpOw0KISAgICAgICAvKiBQdXQgYSBmYWtlIGp1 bXAgYWZ0ZXIgdGhlIGxhYmVsLCBsZXN0IHNvbWUgb3B0aW1pemF0aW9uIG1p Z2h0DQohIAkgZGVsZXRlIHRoZSBiYXJyaWVyIGFuZCBMQUIuICAqLw0KISAg ICAgICBlbWl0X2p1bXBfaW5zbiAoZ2VuX2R1bW15X2p1bXAgKCkpOw0KISAg ICAgfQ0KICAgIGVsc2UNCiEgICAgIHsNCiEgICAgICAgZW1pdF9qdW1wX2lu c24gKGdlbl9jYXNlc2lfanVtcF8xIChyZWcyLCBvcGVyYW5kc1szXSkpOw0K ISAgICAgfQ0KICAgIC8qIEZvciBTSDIgYW5kIG5ld2VyLCB0aGUgQUREUl9E SUZGX1ZFQyBpcyBub3QgYWN0dWFsbHkgcmVsYXRpdmUgdG8NCiAgICAgICBv cGVyYW5kc1szXSwgYnV0IHRvIGxhYi4gIFdlIHdpbGwgZml4IHRoaXMgdXAg aW4NCiAgICAgICBtYWNoaW5lX2RlcGVuZGVudF9yZW9yZy4gICovDQotLS0g MzI5NiwzMzA0IC0tLS0NCiAgCQkJICAgcmVnKSk7DQogICAgZW1pdF9pbnNu IChnZW5fY2FzZXNpX3dvcmtlcl8wIChyZWcyLCByZWcsIG9wZXJhbmRzWzNd KSk7DQogICAgaWYgKFRBUkdFVF9TSDIpDQohICAgICBlbWl0X2p1bXBfaW5z biAoZ2VuX2Nhc2VzaV9qdW1wXzIgKHJlZzIsIGdlbl9sYWJlbF9ydHggKCks IG9wZXJhbmRzWzNdKSk7DQogICAgZWxzZQ0KISAgICAgZW1pdF9qdW1wX2lu c24gKGdlbl9jYXNlc2lfanVtcF8xIChyZWcyLCBvcGVyYW5kc1szXSkpOw0K ICAgIC8qIEZvciBTSDIgYW5kIG5ld2VyLCB0aGUgQUREUl9ESUZGX1ZFQyBp cyBub3QgYWN0dWFsbHkgcmVsYXRpdmUgdG8NCiAgICAgICBvcGVyYW5kc1sz XSwgYnV0IHRvIGxhYi4gIFdlIHdpbGwgZml4IHRoaXMgdXAgaW4NCiAgICAg ICBtYWNoaW5lX2RlcGVuZGVudF9yZW9yZy4gICovDQpkaWZmIC1OIC1QIC1y IC1jIC91c3IxL3J0ZW1zL3dvcmsvb3JpZ2luYWwvZ2NjLTIuOTUvZ2NjL2Nv bmZpZy9zcGFyYy9ydGVtc2VsZi5oIGdjYy0yLjk1L2djYy9jb25maWcvc3Bh cmMvcnRlbXNlbGYuaA0KKioqIC91c3IxL3J0ZW1zL3dvcmsvb3JpZ2luYWwv Z2NjLTIuOTUvZ2NjL2NvbmZpZy9zcGFyYy9ydGVtc2VsZi5oCVdlZCBEZWMg MzEgMTg6MDA6MDAgMTk2OQ0KLS0tIGdjYy0yLjk1L2djYy9jb25maWcvc3Bh cmMvcnRlbXNlbGYuaAlNb24gQXVnICAyIDEyOjIyOjM3IDE5OTkNCioqKioq KioqKioqKioqKg0KKioqIDAgKioqKg0KLS0tIDEsMzUgLS0tLQ0KKyAvKiBE ZWZpbml0aW9ucyBmb3IgcnRlbXMgdGFyZ2V0aW5nIGEgU1BBUkMgdXNpbmcg YS5vdXQuDQorICAgIENvcHlyaWdodCAoQykgMTk5NiwgMTk5NyBGcmVlIFNv ZnR3YXJlIEZvdW5kYXRpb24sIEluYy4NCisgICAgQ29udHJpYnV0ZWQgYnkg Sm9lbCBTaGVycmlsbCAoam9lbEBPQVJjb3JwLmNvbSkuDQorIA0KKyBUaGlz IGZpbGUgaXMgcGFydCBvZiBHTlUgQ0MuDQorIA0KKyBHTlUgQ0MgaXMgZnJl ZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1v ZGlmeQ0KKyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFs IFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQ0KKyB0aGUgRnJlZSBT b2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyLCBvciAoYXQg eW91ciBvcHRpb24pDQorIGFueSBsYXRlciB2ZXJzaW9uLg0KKyANCisgR05V IENDIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBi ZSB1c2VmdWwsDQorIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91 dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mDQorIE1FUkNIQU5UQUJJ TElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNl ZSB0aGUNCisgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUg ZGV0YWlscy4NCisgDQorIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNv cHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlDQorIGFsb25n IHdpdGggR05VIENDOyBzZWUgdGhlIGZpbGUgQ09QWUlORy4gIElmIG5vdCwg d3JpdGUgdG8NCisgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgNTkg VGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLA0KKyBCb3N0b24sIE1BIDAyMTEx LTEzMDcsIFVTQS4gICovDQorIA0KKyAjaW5jbHVkZSAic3BhcmMvZWxmLmgi DQorIA0KKyAvKiBTcGVjaWZ5IHByZWRlZmluZWQgc3ltYm9scyBpbiBwcmVw cm9jZXNzb3IuICAqLw0KKyANCisgI3VuZGVmIENQUF9QUkVERUZJTkVTDQor ICNkZWZpbmUgQ1BQX1BSRURFRklORVMgIi1Ec3BhcmMgLURfX0dDQ19ORVdf VkFSQVJHU19fIC1EcnRlbXMgLURfX3J0ZW1zX18gXA0KKyAgIC1Bc3lzdGVt KHJ0ZW1zKSAtQWNwdShzcGFyYykgLUFtYWNoaW5lKHNwYXJjKSINCisgDQor IC8qIEdlbmVyYXRlIGNhbGxzIHRvIG1lbWNweSwgbWVtY21wIGFuZCBtZW1z ZXQuICAqLw0KKyAjaWZuZGVmIFRBUkdFVF9NRU1fRlVOQ1RJT05TDQorICNk ZWZpbmUgVEFSR0VUX01FTV9GVU5DVElPTlMNCisgI2VuZGlmDQorIA0KKyAv KiBlbmQgb2Ygc3BhcmMvcnRlbXMuaCAqLw0KZGlmZiAtTiAtUCAtciAtYyAv dXNyMS9ydGVtcy93b3JrL29yaWdpbmFsL2djYy0yLjk1L2djYy9jb25maWd1 cmUuaW4gZ2NjLTIuOTUvZ2NjL2NvbmZpZ3VyZS5pbg0KKioqIC91c3IxL3J0 ZW1zL3dvcmsvb3JpZ2luYWwvZ2NjLTIuOTUvZ2NjL2NvbmZpZ3VyZS5pbglU dWUgSnVsIDEzIDE5OjM5OjI2IDE5OTkNCi0tLSBnY2MtMi45NS9nY2MvY29u ZmlndXJlLmluCVdlZCBBdWcgIDQgMTM6MDY6MzIgMTk5OQ0KKioqKioqKioq KioqKioqDQoqKiogMTMyNywxMzQwICoqKioNCiAgCQl0bWFrZV9maWxlPSJp Mzg2L3QtZ28zMiB0LXJ0ZW1zIg0KICAJCTs7DQogIGNoYW5nZXF1b3RlKCwp ZG5sDQohIAlpWzM0NTY3XTg2LSotcnRlbXNlbGYqKQ0KICBjaGFuZ2VxdW90 ZShbLF0pZG5sDQogIAkJY3B1X3R5cGU9aTM4Ng0KICAJCXRtX2ZpbGU9aTM4 Ni9ydGVtc2VsZi5oDQohIAkJdG1ha2VfZmlsZT0iaTM4Ni90LWkzODZiYXJl IHQtcnRlbXMiDQogIAkJOzsNCiAgY2hhbmdlcXVvdGUoLClkbmwNCiEgCWlb MzQ1NjddODYtKi1ydGVtcyopDQogIGNoYW5nZXF1b3RlKFssXSlkbmwNCiAg CQljcHVfdHlwZT1pMzg2DQogIAkJdG1fZmlsZT1pMzg2L3J0ZW1zLmgNCi0t LSAxMzI3LDEzNDEgLS0tLQ0KICAJCXRtYWtlX2ZpbGU9ImkzODYvdC1nbzMy IHQtcnRlbXMiDQogIAkJOzsNCiAgY2hhbmdlcXVvdGUoLClkbmwNCiEgCWlb MzQ1NjddODYtKi1ydGVtcyp8aVszNDU2N104Ni0qLXJ0ZW1zZWxmKikNCiAg Y2hhbmdlcXVvdGUoWyxdKWRubA0KICAJCWNwdV90eXBlPWkzODYNCiAgCQl0 bV9maWxlPWkzODYvcnRlbXNlbGYuaA0KISAJCWV4dHJhX3BhcnRzPSJjcnRi ZWdpbi5vIGNydGVuZC5vIGNydGkubyBjcnRuLm8iDQohIAkJdG1ha2VfZmls ZT0iaTM4Ni90LXJ0ZW1zLWkzODYgaTM4Ni90LWNydHN0dWZmIHQtcnRlbXMi DQogIAkJOzsNCiAgY2hhbmdlcXVvdGUoLClkbmwNCiEgCWlbMzQ1NjddODYt Ki1ydGVtc2NvZmYqKQ0KICBjaGFuZ2VxdW90ZShbLF0pZG5sDQogIAkJY3B1 X3R5cGU9aTM4Ng0KICAJCXRtX2ZpbGU9aTM4Ni9ydGVtcy5oDQoqKioqKioq KioqKioqKioNCioqKiAyMTAwLDIxMTIgKioqKg0KICAJCWV4dHJhX2hlYWRl cnM9bWF0aC02ODg4MS5oDQogIAkJZmxvYXRfZm9ybWF0PW02OGsNCiAgCQk7 Ow0KISAJbTY4ay0qLXJ0ZW1zKikNCiAgCQl0bWFrZV9maWxlPSJtNjhrL3Qt bTY4a2JhcmUgdC1ydGVtcyINCiAgCQl0bV9maWxlPW02OGsvcnRlbXMuaA0K ICAJCWV4dHJhX2hlYWRlcnM9bWF0aC02ODg4MS5oDQogIAkJZmxvYXRfZm9y bWF0PW02OGsNCiAgCQk7Ow0KLSANCiAgCW04OGstZGctZGd1eCopDQogIAkJ Y2FzZSAkbWFjaGluZSBpbg0KICAJCSAgbTg4ay1kZy1kZ3V4YmNzKikNCi0t LSAyMTAxLDIxMTggLS0tLQ0KICAJCWV4dHJhX2hlYWRlcnM9bWF0aC02ODg4 MS5oDQogIAkJZmxvYXRfZm9ybWF0PW02OGsNCiAgCQk7Ow0KISAJbTY4ay0q LXJ0ZW1zZWxmKikNCiEgCQl0bWFrZV9maWxlPSJtNjhrL3QtbTY4a2JhcmUg dC1ydGVtcyBtNjhrL3QtY3J0c3R1ZmYiDQohIAkJdG1fZmlsZT1tNjhrL3J0 ZW1zZWxmLmgNCiEgCQlleHRyYV9oZWFkZXJzPW1hdGgtNjg4ODEuaA0KISAJ CWZsb2F0X2Zvcm1hdD1tNjhrDQohIAkJOzsNCiEgCW02OGstKi1ydGVtc2Nv ZmYqfG02OGstKi1ydGVtcyopDQogIAkJdG1ha2VfZmlsZT0ibTY4ay90LW02 OGtiYXJlIHQtcnRlbXMiDQogIAkJdG1fZmlsZT1tNjhrL3J0ZW1zLmgNCiAg CQlleHRyYV9oZWFkZXJzPW1hdGgtNjg4ODEuaA0KICAJCWZsb2F0X2Zvcm1h dD1tNjhrDQogIAkJOzsNCiAgCW04OGstZGctZGd1eCopDQogIAkJY2FzZSAk bWFjaGluZSBpbg0KICAJCSAgbTg4ay1kZy1kZ3V4YmNzKikNCioqKioqKioq KioqKioqKg0KKioqIDI2MzEsMjYzNyAqKioqDQogIAkJOzsNCiAgCW1pcHM2 NG9yaW9uLSotcnRlbXMqKQ0KICAJCXRtX2ZpbGU9Im1pcHMvZWxmb3Jpb24u aCBtaXBzL2VsZjY0LmggbWlwcy9ydGVtczY0LmgiDQohIAkJdG1ha2VfZmls ZT0ibWlwcy90LWVjb2ZmIHQtcnRlbXMiDQogIAkJOzsNCiAgCW1pcHN0eDM5 ZWwtKi1lbGYqKQ0KICAJCXRtX2ZpbGU9Im1pcHMvcjM5MDAuaCBtaXBzL2Vs ZmwuaCBtaXBzL2FiaTY0LmgiDQotLS0gMjYzNywyNjQ0IC0tLS0NCiAgCQk7 Ow0KICAJbWlwczY0b3Jpb24tKi1ydGVtcyopDQogIAkJdG1fZmlsZT0ibWlw cy9lbGZvcmlvbi5oIG1pcHMvZWxmNjQuaCBtaXBzL3J0ZW1zNjQuaCINCiEg ICAgICAgICAgICAgICAgIHRtX2ZpbGU9Im1pcHMvZWxmb3Jpb24uaCBtaXBz L2VsZjY0LmggbWlwcy9ydGVtczY0LmgiDQohIAkJdG1ha2VfZmlsZT0ibWlw cy90LWVsZiB0LXJ0ZW1zIg0KICAJCTs7DQogIAltaXBzdHgzOWVsLSotZWxm KikNCiAgCQl0bV9maWxlPSJtaXBzL3IzOTAwLmggbWlwcy9lbGZsLmggbWlw cy9hYmk2NC5oIg0KKioqKioqKioqKioqKioqDQoqKiogMzA3NiwzMDgyICoq KioNCiAgCQl0bWFrZV9maWxlPXNwYXJjL3Qtc3Vub3M0MQ0KICAJCXhtYWtl X2ZpbGU9eC1seW54DQogIAkJOzsNCiEgCXNwYXJjLSotcnRlbXMqKQ0KICAJ CXRtYWtlX2ZpbGU9InNwYXJjL3Qtc3BhcmNiYXJlIHQtcnRlbXMiDQogIAkJ dG1fZmlsZT1zcGFyYy9ydGVtcy5oDQogIAkJOzsNCi0tLSAzMDgzLDMwOTYg LS0tLQ0KICAJCXRtYWtlX2ZpbGU9c3BhcmMvdC1zdW5vczQxDQogIAkJeG1h a2VfZmlsZT14LWx5bngNCiAgCQk7Ow0KISAJc3BhcmMtKi1ydGVtcyp8c3Bh cmMtKi1ydGVtc2VsZiopDQohIAkJdG1fZmlsZT0ic3BhcmMvcnRlbXNlbGYu aCINCiEgCQl0bWFrZV9maWxlPSJzcGFyYy90LWVsZiB0LXJ0ZW1zIg0KISAJ CWV4dHJhX3BhcnRzPSJjcnRpLm8gY3J0bi5vIGNydGJlZ2luLm8gY3J0ZW5k Lm8iDQohIAkJI2Zsb2F0X2Zvcm1hdD1pMTI4DQohIAkJZmxvYXRfZm9ybWF0 PWk2NA0KISAJCTs7DQohIAlzcGFyYy0qLXJ0ZW1zYW91dCopDQogIAkJdG1h a2VfZmlsZT0ic3BhcmMvdC1zcGFyY2JhcmUgdC1ydGVtcyINCiAgCQl0bV9m aWxlPXNwYXJjL3J0ZW1zLmgNCiAgCQk7Ow0KZGlmZiAtTiAtUCAtciAtYyAv dXNyMS9ydGVtcy93b3JrL29yaWdpbmFsL2djYy0yLjk1L2djYy90LWVsZiBn Y2MtMi45NS9nY2MvdC1lbGYNCioqKiAvdXNyMS9ydGVtcy93b3JrL29yaWdp bmFsL2djYy0yLjk1L2djYy90LWVsZglXZWQgRGVjIDMxIDE4OjAwOjAwIDE5 NjkNCi0tLSBnY2MtMi45NS9nY2MvdC1lbGYJTW9uIEF1ZyAgMiAxMjoyMjoz NyAxOTk5DQoqKioqKioqKioqKioqKioNCioqKiAwICoqKioNCi0tLSAxLDk2 IC0tLS0NCisgQ09ORklHMl9ICT0gJChzcmNkaXIpL2NvbmZpZy9taXBzL2Vj b2ZmLmgNCisgDQorICMgV2UgaGF2ZSBhIHByZW1hZGUgaW5zbi1hdHRydGFi LmMgdG8gc2F2ZSB0aGUgaG91ciBpdCB0YWtlcyB0byBydW4gZ2VuYXR0cnRh Yi4NCisgIyBQUkVNQURFX0FUVFJUQUIgPSAkKHNyY2RpcikvY29uZmlnL21p cHMvbWlwcy1hdC5jDQorICMgUFJFTUFERV9BVFRSVEFCX01EID0gJChzcmNk aXIpL2NvbmZpZy9taXBzL21pcHMtYXQubWQNCisgDQorICMgU3VwcHJlc3Mg YnVpbGRpbmcgbGliZ2NjMS5hLCBzaW5jZSB0aGUgTUlQUyBjb21waWxlciBw b3J0IGlzIGNvbXBsZXRlDQorICMgYW5kIGRvZXMgbm90IG5lZWQgYW55dGhp bmcgZnJvbSBsaWJnY2MxLmEuDQorIExJQkdDQzEgPQ0KKyANCisgRVhUUkFf TVVMVElMSUJfUEFSVFMgPSBjcnRiZWdpbi5vIGNydGVuZC5vDQorICMgRG9u J3QgbGV0IENUT1JfTElTVCBlbmQgdXAgaW4gc2RhdGEgc2VjdGlvbi4NCisg Q1JUU1RVRkZfVF9DRkxBR1MgPSAtRyAwDQorIA0KKyAjIFdoZW4gYnVpbGRp bmcgYSBjcm9zcyBjb21waWxlciwgcHV0IHRoZSBtaXBzMTYgc3VwcG9ydCBm dW5jdGlvbnMgaW4NCisgIyBsaWJnY2MxLmEuDQorIENST1NTX0xJQkdDQzEg PSBsaWJnY2MxLWFzbS5hDQorIExJQjFBU01TUkMgPSBtaXBzL21pcHMxNi5T DQorIExJQjFBU01GVU5DUyA9IF9tMTZhZGRzZjMgX20xNnN1YnNmMyBfbTE2 bXVsc2YzIF9tMTZkaXZzZjMgXA0KKyAJX20xNmVxc2YyIF9tMTZuZXNmMiBf bTE2Z3RzZjIgX20xNmdlc2YyIF9tMTZsZXNmMiBfbTE2bHRzZjIgXA0KKyAJ X20xNmZsdHNpc2YgX20xNmZpeHNmc2kgXA0KKyAJX20xNmFkZGRmMyBfbTE2 c3ViZGYzIF9tMTZtdWxkZjMgX20xNmRpdmRmMyBcDQorIAlfbTE2ZXh0c2Zk ZjIgX20xNnRyZGZzZjIgXA0KKyAJX20xNmVxZGYyIF9tMTZuZWRmMiBfbTE2 Z3RkZjIgX20xNmdlZGYyIF9tMTZsZWRmMiBfbTE2bHRkZjIgXA0KKyAJX20x NmZsdHNpZGYgX20xNmZpeGRmc2kgXA0KKyAJX20xNnJldHNmIF9tMTZyZXRk ZiBcDQorIAlfbTE2c3R1YjEgX20xNnN0dWIyIF9tMTZzdHViNSBfbTE2c3R1 YjYgX20xNnN0dWI5IF9tMTZzdHViMTAgXA0KKyAJX20xNnN0dWJzZjAgX20x NnN0dWJzZjEgX20xNnN0dWJzZjIgX20xNnN0dWJzZjUgX20xNnN0dWJzZjYg XA0KKyAJX20xNnN0dWJzZjkgX20xNnN0dWJzZjEwIFwNCisgCV9tMTZzdHVi ZGYwIF9tMTZzdHViZGYxIF9tMTZzdHViZGYyIF9tMTZzdHViZGY1IF9tMTZz dHViZGY2IFwNCisgCV9tMTZzdHViZGY5IF9tMTZzdHViZGYxMA0KKyANCisg IyBXZSBtdXN0IGJ1aWxkIGxpYmdjYzIuYSB3aXRoIC1HIDAsIGluIGNhc2Ug dGhlIHVzZXIgd2FudHMgdG8gbGluaw0KKyAjIHdpdGhvdXQgdGhlICRncCBy ZWdpc3Rlci4NCisgVEFSR0VUX0xJQkdDQzJfQ0ZMQUdTID0gLUcgMA0KKyAN CisgIyBmcC1iaXQgYW5kIGRwLWJpdCBhcmUgcmVhbGx5IHBhcnQgb2YgbGli Z2NjMSwgYnV0IHRoaXMgd2lsbCBjYXVzZQ0KKyAjIHRoZW0gdG8gYmUgYnVp bHQgY29ycmVjdGx5LCBzby4uLiBbdGFrZW4gZnJvbSB0LXNwYXJjbGl0ZV0N CisgTElCMkZVTkNTX0VYVFJBID0gZnAtYml0LmMgZHAtYml0LmMNCisgDQor IGRwLWJpdC5jOiAkKHNyY2RpcikvY29uZmlnL2ZwLWJpdC5jDQorIAllY2hv ICcjaWZkZWYgX19NSVBTRUxfXycgPiBkcC1iaXQuYw0KKyAJZWNobyAnI2Rl ZmluZSBGTE9BVF9CSVRfT1JERVJfTUlTTUFUQ0gnID4+IGRwLWJpdC5jDQor IAllY2hvICcjZW5kaWYnID4+IGRwLWJpdC5jDQorIAllY2hvICcjZGVmaW5l IFVTX1NPRlRXQVJFX0dPRkFTVCcgPj4gZHAtYml0LmMNCisgCWNhdCAkKHNy Y2RpcikvY29uZmlnL2ZwLWJpdC5jID4+IGRwLWJpdC5jDQorIA0KKyBmcC1i aXQuYzogJChzcmNkaXIpL2NvbmZpZy9mcC1iaXQuYw0KKyAJZWNobyAnI2Rl ZmluZSBGTE9BVCcgPiBmcC1iaXQuYw0KKyAJZWNobyAnI2lmZGVmIF9fTUlQ U0VMX18nID4+IGZwLWJpdC5jDQorIAllY2hvICcjZGVmaW5lIEZMT0FUX0JJ VF9PUkRFUl9NSVNNQVRDSCcgPj4gZnAtYml0LmMNCisgCWVjaG8gJyNlbmRp ZicgPj4gZnAtYml0LmMNCisgCWVjaG8gJyNkZWZpbmUgVVNfU09GVFdBUkVf R09GQVNUJyA+PiBmcC1iaXQuYw0KKyAJY2F0ICQoc3JjZGlyKS9jb25maWcv ZnAtYml0LmMgPj4gZnAtYml0LmMNCisgDQorICMgQnVpbGQgdGhlIGxpYnJh cmllcyBmb3IgYm90aCBoYXJkIGFuZCBzb2Z0IGZsb2F0aW5nIHBvaW50DQor IA0KKyBNVUxUSUxJQl9PUFRJT05TID0gbXNvZnQtZmxvYXQvbXNpbmdsZS1m bG9hdCBFTC9FQiBtaXBzMS9taXBzMw0KKyBNVUxUSUxJQl9ESVJOQU1FUyA9 IHNvZnQtZmxvYXQgc2luZ2xlIGVsIGViIG1pcHMxIG1pcHMzDQorIE1VTFRJ TElCX01BVENIRVMgPSBtc2luZ2xlLWZsb2F0PW00NjUwDQorIA0KKyBMSUJH Q0MgPSBzdG1wLW11bHRpbGliDQorIElOU1RBTExfTElCR0NDID0gaW5zdGFs bC1tdWx0aWxpYg0KKyANCisgIyBBZGQgYWRkaXRpb25hbCBkZXBlbmRlbmNp ZXMgdG8gcmVjb21waWxlIHNlbGVjdGVkIG1vZHVsZXMgd2hlbmV2ZXIgdGhl DQorICMgdG0uaCBmaWxlIGNoYW5nZXMuICBUaGUgZmlsZXMgY29tcGlsZWQg YXJlOg0KKyAjDQorICMJZ2NjLmMJCSgqX1NQRUMgY2hhbmdlcykNCisgIwl0 b3BsZXYuYwkobmV3IHN3aXRjaGVzICsgYXNzZW1ibHkgb3V0cHV0IGNoYW5n ZXMpDQorICMJc2Rib3V0LmMJKGRlYnVnIGZvcm1hdCBjaGFuZ2VzKQ0KKyAj CWRieG91dC5jCShkZWJ1ZyBmb3JtYXQgY2hhbmdlcykNCisgIwlkd2FyZm91 dC5jCShkZWJ1ZyBmb3JtYXQgY2hhbmdlcykNCisgIwlmaW5hbC5jCQkoYXNz ZW1ibHkgb3V0cHV0IGNoYW5nZXMpDQorICMJdmFyYXNtLmMJKGFzc2VtYmx5 IG91dHB1dCBjaGFuZ2VzKQ0KKyAjCWNzZS5jCQkoY29zdCBmdW5jdGlvbnMp DQorICMJaW5zbi1vdXRwdXQuYwkocG9zc2libGUgaWZkZWYgY2hhbmdlcyBp biB0bS5oKQ0KKyAjCXJlZ2NsYXNzLmMJKGZpeGVkL2NhbGwgdXNlZCByZWdp c3RlciBjaGFuZ2VzKQ0KKyAjCWNjY3AuYwkJKG5ldyBwcmVwcm9jZXNzb3Ig bWFjcm9zLCAtdiB2ZXJzaW9uICMpDQorICMJZXhwbG93LmMJKEdPX0lGX0xF R0lUSU1BVEVfQUREUkVTUykNCisgIwlyZWNvZy5jCQkoR09fSUZfTEVHSVRJ TUFURV9BRERSRVNTKQ0KKyAjCXJlbG9hZC5jCShHT19JRl9MRUdJVElNQVRF X0FERFJFU1MpDQorIA0KKyBnY2MubzogJChDT05GSUcyX0gpDQorIHRvcGxl di5vOiAkKENPTkZJRzJfSCkNCisgc2Rib3V0Lm86ICQoQ09ORklHMl9IKQ0K KyBkYnhvdXQubzogJChDT05GSUcyX0gpDQorIGR3YXJmb3V0Lm86ICQoQ09O RklHMl9IKQ0KKyBmaW5hbC5vOiAkKENPTkZJRzJfSCkNCisgdmFyYXNtLm86 ICQoQ09ORklHMl9IKQ0KKyBjc2UubzogJChDT05GSUcyX0gpDQorIGluc24t b3V0cHV0Lm86ICQoQ09ORklHMl9IKQ0KKyByZWdjbGFzcy5vOiAkKENPTkZJ RzJfSCkNCisgY2NjcC5vOiAkKENPTkZJRzJfSCkNCisgZXhwbG93Lm86ICQo Q09ORklHMl9IKQ0KKyByZWNvZy5vOiAkKENPTkZJRzJfSCkNCisgcmVsb2Fk Lm86ICQoQ09ORklHMl9IKQ0K ---1496293000-453236816-933957971=:27834-- From gcc-return-8871-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 18:46:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27352 invoked by alias); 6 Aug 1999 18:45:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27243 invoked from network); 6 Aug 1999 18:45:26 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 6 Aug 1999 18:45:26 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id MAA25790; Fri, 6 Aug 1999 12:38:54 -0600 X-Mailer: exmh version 2.0.2 To: "Christopher R. Jones" cc: egcs@egcs.cygnus.com Subject: Re: compile warning Reply-To: law@cygnus.com In-reply-to: Your message of Fri, 06 Aug 1999 11:46:58 EDT. <3.0.32.19990806114653.009798e0@mail.interlog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Aug 1999 12:38:54 -0600 Message-ID: <25787.933964734@upchuck.cygnus.com> From: Jeffrey A Law In message <3.0.32.19990806114653.009798e0@mail.interlog.com>you write: > Building gcc-2.95 on Solaris 2.7, Intel using egcs-1.1.2 I get a number of > errors similiar to: > > "..../toplev.c 1178 warning initialization from incompatible pointer type" Nothing to be worried about. jeff From gcc-return-8872-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 19:04:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30366 invoked by alias); 6 Aug 1999 19:04:22 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30348 invoked from network); 6 Aug 1999 19:04:10 -0000 Received: from venus.nmsmn.com (198.246.177.5) by egcs.cygnus.com with SMTP; 6 Aug 1999 19:04:10 -0000 Received: from iris.nmsmn.com (iris.nmsmn.com [192.168.60.30]) by venus.nmsmn.com (8.9.3/8.9.3) with ESMTP id OAA22511 for ; Fri, 6 Aug 1999 14:04:08 -0500 (CDT) Received: by iris.nmsmn.com with Internet Mail Service (5.5.2448.0) id ; Fri, 6 Aug 1999 14:02:06 -0500 Message-ID: <76EBA0999931D311926C009027557B56349641@iris.nmsmn.com> From: "Putney, Jeff" To: gcc@egcs.cygnus.com Subject: RE: Illegal instruction (core dumped) on i586 Date: Fri, 6 Aug 1999 14:01:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" So some yahoo really thinks gcc should be distributed as source and RedHat RPMs? Why redhat? Why not distribute binaries as solaris packages, or HP/UX packages, or AIX packages, or DG/UX packages and let's have them do packages for Slackware and Debian, and all the other linux distrobutions while we're asking. Then, while we are on a roll, let's have them do a package for each of those OS's for each distrobution for each architecture they run on. Linux will run on the palm pilot, don't forget to make a distrobution for that. Oh, wait, we need different packages depending on library versions, and type of assembler and linker. So, why single out RedHat on an x86? Is there really a that much greater density of stupidity on that particular platform. If so, what does a group of compiler hackers have to gain from such a group by catering to them? A bunch of bug reports because the compiler wouldn't fix their syntax errors for them and moronic code examples to point to and laugh at is about the only payback they would get. --jeff (not the Law, but a jeff of a different flavor) From gcc-return-8873-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 19:46:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2866 invoked by alias); 6 Aug 1999 19:46:45 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2813 invoked from network); 6 Aug 1999 19:46:19 -0000 Received: from smtp.ucla.edu (HELO serval.noc.ucla.edu) (169.232.10.57) by egcs.cygnus.com with SMTP; 6 Aug 1999 19:46:19 -0000 Received: from cs.ucla.edu (ts34-13.wla.ts.ucla.edu [164.67.22.42]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id MAA26282; Fri, 6 Aug 1999 12:45:47 -0700 (PDT) Message-ID: <37AB3C1C.9E7C5C2C@cs.ucla.edu> Date: Fri, 06 Aug 1999 12:48:44 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Vu Hung Quan CC: egcs@egcs.cygnus.com Subject: Re: gcc-2.95 rpm References: <99080514401800.19963@binaire.cx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I have uploaded a new rpm version of gcc-2.95 in rh contrib ftp , these > will be avalaible shortly : I repeat --- please withdraw your RPMs from RedHat. In addition to stdlibc++ they have other problems. RPMs prepared by H.J. Lu of VA Linux work fine. Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8874-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 20:00:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5601 invoked by alias); 6 Aug 1999 20:00:53 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5583 invoked from network); 6 Aug 1999 20:00:50 -0000 Received: from ale.atd.ucar.edu (128.117.80.15) by egcs.cygnus.com with SMTP; 6 Aug 1999 20:00:50 -0000 Received: from stout.atd.ucar.edu (stout.atd.ucar.edu [128.117.80.30]) by ale.atd.ucar.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA28347; Fri, 6 Aug 1999 14:00:49 -0600 (MDT) Received: from ale.atd.ucar.edu (ale.atd.ucar.edu [128.117.80.15]) by stout.atd.ucar.edu (8.8.8/8.8.8) with ESMTP id OAA01612; Fri, 6 Aug 1999 14:00:48 -0600 (MDT) Message-Id: <199908062000.OAA01612@stout.atd.ucar.edu> To: lfarkas@mindmaker.hu cc: gcc@gcc.gnu.org Subject: Re: mem_fun family (for_each, bind..) In-reply-to: Message on "Fri, 06 Aug 1999 13:50:16 +0200." <37AACBF8.B82A9B@mindmaker.hu> Date: Fri, 06 Aug 1999 14:00:47 -0600 From: "Gary Granger" The draft standard I have lists the bind2nd declaration as follows: template binder2nd bind2nd(const Operation&, const T&); It looks like the type 'double' you are passing cannot be used since it is not constant. I replaced your reference with a pointer and it compiled and ran with no problems: Across the ether fly the words of Levente Farkas: ... > void f(double& d) const { ++d; } void f(double *d) const { ++(*d); } ... > std::bind2nd(std::mem_fun(&A::f), d)); std::bind2nd(std::mem_fun(&A::f), &d)); > ... > ms's compiler don't support it), but this simple example can't compile even > on the latest egcs/gcc - 2.95! > or am I wrong ? If you are not sure whether this "simple example" complies with the standard, then perhaps it is not so simple, and you should instead let the newsgroups answer the STL question *before* asking the bug question. gary From gcc-return-8875-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 20:16:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7500 invoked by alias); 6 Aug 1999 20:16:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7465 invoked from network); 6 Aug 1999 20:16:40 -0000 Received: from newton.math.purdue.edu (root@128.210.3.6) by egcs.cygnus.com with SMTP; 6 Aug 1999 20:16:40 -0000 Received: from polya.math.purdue.edu (lucier@polya.math.purdue.edu [128.210.3.194]) by newton.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.3) with ESMTP id PAA08449; Fri, 6 Aug 1999 15:16:27 -0500 (EST) Received: (from lucier@localhost) by polya.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.1) id PAA00514; Fri, 6 Aug 1999 15:16:21 -0500 (EST) Date: Fri, 6 Aug 1999 15:16:21 -0500 (EST) From: Brad Lucier Message-Id: <199908062016.PAA00514@polya.math.purdue.edu> To: gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, lucier@math.purdue.edu Subject: Re: big slowdown in egcs-1.1.2->gcc-2.95 on alpha Cc: staff@math.purdue.edu, hosking@cs.purdue.edu, wilker@math.purdue.edu X-Sun-Charset: US-ASCII To follow up on my comments that gcc-2.95 is much slower than egcs-1.1.2 on the alpha-ev6 for some files, here are some timing data for a profiled cc1 on alphaev6-unknown-linux-gnu with glibc-2.1.1, binutils-2.9.5.0.4, and kernel 2.2.10. Because the various timings on this machine are screwed up, I don't know how to interpret the information precisely. But it can give you a an idea of the relative times that various parts of the process took. gcc was called with gcc -fPIC -save-temps -O1 on eight relatively large files (basically, each of these files contains a 25,000+ line procedure to be compiled, with a total of 18 local variables and one argument). The output from cc1 on the first of these files (which is typical) is: __copysignf copysignf __copysign copysign __fabsf fabsf __fabs fabs __floorf __floor floorf floor __fdimf fdimf __fdim fdim ___H__20_g0_2d_1 ___init_proc ____20_g0_2d_1 time in parse: 21.472976 time in integration: 0.000000 time in jump: 1.503040 time in cse: 0.000000 time in gcse: 0.000000 time in loop: 0.000000 time in cse2: 0.000000 time in branch-prob: 0.000000 time in flow: 5.866736 time in combine: 0.000000 time in regmove: 0.000000 time in sched: 0.000000 time in local-alloc: 0.000000 time in global-alloc: 44.732032 time in flow2: 0.000000 time in sched2: 0.000000 time in shorten-branch: 1.636752 time in stack-reg: 0.000000 time in final: 7.841184 time in varconst: 0.031232 time in symout: 0.000000 time in dump: 0.000000 If I read this correctly, it's spending a lot of time in reload (global_alloc isn't in the call graph, and reload is; in toplev.c, you see that one or the other is called, but the time is reported above as global_alloc either way). Perhaps there's a problem in reload. The gprof output file can be found at http://www.math.purdue.edu/~lucier/gmon.summary.gz The summary information from gprof for cc1 begins: Flat profile: Each sample counts as 0.000976562 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 7.74 2.74 2.74 90228 0.03 0.06 order_regs_for_reload 6.94 5.21 2.46 358919 0.01 0.01 find_reloads 6.82 7.62 2.42 8 302.49 4312.47 yyparse 6.51 9.93 2.31 42370698 0.00 0.00 bitmap_bit_p 3.64 11.22 1.29 2455661 0.00 0.00 yylex 2.60 12.15 0.92 302171 0.00 0.00 record_reg_classes 2.50 13.03 0.89 hard_reg_use_compare 2.32 13.85 0.82 24 34.26 58.61 stupid_life_analysis 1.89 14.52 0.67 512830 0.00 0.00 for_each_rtx 1.65 15.11 0.59 8208660 0.00 0.00 count_pseudo Some selected information from the call graph about reload, which seems to take a long time: ----------------------------------------------- 2.74 2.27 90228/90228 find_reload_regs [7] [8] 14.1 2.74 2.27 90228 order_regs_for_reload [8] 0.59 0.91 8208660/8208660 count_pseudo [23] 0.59 0.00 10827360/42370698 bitmap_bit_p [13] 0.18 0.00 5503908/5503956 bitmap_clear [93] 0.00 0.00 90228/704750 bitmap_initialize [259] ----------------------------------------------- 0.17 4.56 16/16 reload [6] [9] 13.3 0.17 4.56 16 reload_as_needed [9] 0.26 1.83 90228/90228 emit_reload_insns [15] 0.38 0.95 90228/90228 choose_reload_regs [30] 0.70 0.29 102504/358919 find_reloads [11] 0.04 0.04 256335/864560 note_stores [74] 0.02 0.00 90228/90228 subst_reloads [247] 0.00 0.02 12276/268691 eliminate_regs_in_insn [52] 0.01 0.00 50798/84370 set_offsets_for_label [312] 0.01 0.00 90228/2814858 asm_noperands [96] 0.00 0.00 12276/268691 update_eliminable_offsets [216] 0.00 0.00 16/40 set_initial_elim_offsets [475] ----------------------------------------------- 0.21 3.32 24/24 reload [6] [10] 10.0 0.21 3.32 24 calculate_needs_all_insns [10] 1.76 0.74 256415/358919 find_reloads [11] 0.06 0.42 256415/268691 eliminate_regs_in_insn [52] 0.21 0.00 90228/90228 calculate_needs [83] 0.07 0.01 122572/122572 set_label_offsets [146] 0.03 0.00 256415/268691 update_eliminable_offsets [216] 0.02 0.00 256415/1897960 single_set [109] ----------------------------------------------- 0.70 0.29 102504/358919 reload_as_needed [9] 1.76 0.74 256415/358919 calculate_needs_all_insns [10] [11] 9.8 2.46 1.03 358919 find_reloads [11] 0.19 0.14 219242/243152 push_reload [57] 0.09 0.14 358911/1750922 extract_insn [33] 0.13 0.00 1993307/3091999 reg_fits_class_p [88] 0.08 0.02 310922/310922 combine_reloads [123] 0.03 0.08 92668/92668 find_reloads_address [125] 0.08 0.00 1692578/1910746 reg_class_subset_p [136] 0.03 0.00 358919/1897960 single_set [109] 0.02 0.00 237120/237388 reg_alternate_class [281] 0.01 0.00 237120/355215 reg_preferred_class [311] 0.01 0.00 97392/304810 normal_memory_operand [268] 0.00 0.00 676/1014 zap_mask [724] ----------------------------------------------- [12] 6.9 0.92 1.51 218511+1228287 [12] 0.32 0.42 267378+208665 expand_expr [40] 0.10 0.27 246016 gen_movdi [58] 0.09 0.14 56286 expand_binop [80] 0.06 0.10 246688 emit_move_insn_1 [99] 0.02 0.13 25803 do_jump_for_compare [106] 0.08 0.05 65220 store_expr [113] 0.04 0.07 125120 emit_move_insn [120] 0.03 0.06 63104 expand_assignment [130] 0.03 0.04 73195 memory_address [148] 0.03 0.05 25811+2040 emit_cmp_insn [149] 0.03 0.02 25793+2040 do_jump [181] 0.01 0.03 25811 alpha_emit_conditional_branch [188] 0.01 0.02 29226 copy_to_mode_reg [209] 0.01 0.02 28480 force_reg [234] 0.01 0.01 32680 change_address [240] 0.00 0.02 10850 gen_ble [246] 0.01 0.01 25803 compare_from_rtx [264] 0.00 0.01 5233 gen_bgt [300] 0.01 0.00 23795 compare [305] 0.00 0.01 4997 gen_bne [329] 0.01 0.00 10500+37504 force_operand [349] 0.01 0.00 9808 expand_shift [366] 0.00 0.00 2008 gen_bgtu [392] 0.00 0.00 2072 emit_unop_insn [394] 0.00 0.00 1973 gen_beq [407] 0.00 0.00 4088 convert_modes [409] 0.00 0.00 2080 convert_move [426] 0.00 0.00 698 gen_blt [431] 0.00 0.00 140 expand_divmod [456] 0.00 0.00 32 expand_call [459] 0.00 0.00 662 expand_mult [525] 0.00 0.00 52 gen_bge [571] 0.00 0.00 88 copy_to_reg [584] 0.00 0.00 16 emit_libcall_block [595] 0.00 0.00 32 load_register_parameters [623] 0.00 0.00 32 precompute_arguments [628] 0.00 0.00 32 precompute_register_parameters [639] 0.00 0.00 1058 jumpifnot [721] ----------------------------------------------- 0.45 0.00 8208660/42370698 count_pseudo [23] 0.59 0.00 10827360/42370698 order_regs_for_reload [8] 0.63 0.00 11549184/42370698 choose_reload_regs [30] 0.64 0.00 11785494/42370698 finish_spills [25] [13] 6.5 2.31 0.00 42370698 bitmap_bit_p [13] ----------------------------------------------- 0.21 2.03 24/24 rest_of_compilation [5] [14] 6.3 0.21 2.03 24 final [14] 0.22 1.81 497630/497630 final_scan_insn [17] 0.00 0.00 24/5328 oballoc [485] 0.00 0.00 24/48 check_exception_handler_labels [816] 0.00 0.00 24/24 init_insn_eh_region [861] 0.00 0.00 24/104 init_recog [804] 0.00 0.00 24/24 free_insn_eh_region [856] ----------------------------------------------- 0.26 1.83 90228/90228 reload_as_needed [9] [15] 5.9 0.26 1.83 90228 emit_reload_insns [15] 0.05 1.49 121568/121568 gen_reload [22] 0.11 0.02 2218446/2218446 emit_insns_before [114] 0.04 0.00 227736/519956 rtx_equal_p [128] 0.01 0.02 59574/59574 reg_set_p [241] 0.02 0.00 102417/102417 reload_reg_reaches_end_p [250] 0.01 0.01 102409/102409 push_to_sequence [265] 0.02 0.00 35821/35957 reg_mentioned_p [270] 0.01 0.01 35821/864560 note_stores [74] 0.01 0.00 121568/541814 end_sequence [195] 0.01 0.00 71642/1897960 single_set [109] 0.00 0.00 85747/363523 get_last_insn [271] 0.00 0.00 157389/279445 get_insns [371] 0.00 0.00 19159/541814 start_sequence [156] 0.00 0.00 35829/422200 find_reg_note [238] 0.00 0.00 19159/19311 emit_insns [482] 0.00 0.00 1262/1262 delete_output_reload [539] ----------------------------------------------- [16] 5.8 0.39 1.66 417809+698063 [16] 0.20 1.16 317912 build_binary_op [29] 0.15 0.00 707786 default_conversion [101] 0.01 0.06 25861 build_unary_op [155] 0.01 0.00 35813 truthvalue_conversion [310] ----------------------------------------------- Brad Lucier lucier@math.purdue.edu From gcc-return-8876-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 20:54:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12562 invoked by alias); 6 Aug 1999 20:54:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12521 invoked from network); 6 Aug 1999 20:54:35 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 6 Aug 1999 20:54:35 -0000 Received: (qmail 12401 invoked by alias); 6 Aug 1999 20:54:33 -0000 Received: (qmail 12384 invoked from network); 6 Aug 1999 20:54:32 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 6 Aug 1999 20:54:32 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id VAA03606; Fri, 6 Aug 1999 21:53:52 +0100 From: Joern Rennecke Message-Id: <199908062053.VAA03606@phal.cygnus.co.uk> Subject: Re: big slowdown in egcs-1.1.2->gcc-2.95 on alpha In-Reply-To: <199908062016.PAA00514@polya.math.purdue.edu> from Brad Lucier at "Aug 6, 1999 3:16:21 pm" To: lucier@math.purdue.edu (Brad Lucier) Date: Fri, 6 Aug 1999 21:53:52 +0100 (BST) Cc: gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, lucier@math.purdue.edu, staff@math.purdue.edu, hosking@cs.purdue.edu, wilker@math.purdue.edu, bernds@cygnus.com X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > If I read this correctly, it's spending a lot of time in reload > (global_alloc isn't in the call graph, and reload is; in toplev.c, you > see that one or the other is called, but the time is reported above as > global_alloc either way). Perhaps there's a problem in reload. That's the price we pay for doing register spilling on a per-instruction basis, and calling compute_use_by_pseudos twice for every instruction and reload pass. I think we could fix this by using pseudo register birth / death lists instead of complete register sets. From gcc-return-8877-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 21:08:40 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15638 invoked by alias); 6 Aug 1999 21:08:37 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15608 invoked from network); 6 Aug 1999 21:08:33 -0000 Received: from 209-249-66-150.snj0.flashcom.net (HELO ocean.lucon.org) (postfix@209.249.66.150) by egcs.cygnus.com with SMTP; 6 Aug 1999 21:08:33 -0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 8C18A57BA; Fri, 6 Aug 1999 14:08:30 -0700 (PDT) Subject: binutils 2.9.5.0.5 is released. To: wwc@rentec.com (Wolfgang Wander) Date: Fri, 6 Aug 1999 14:08:30 -0700 (PDT) Cc: kjahds@kjahds.com (Kenneth Albanowski), lmfken@lmf.ericsson.se (Kenneth Osterberg), mat@lcs.mit.edu (Mat Hostetter), doughera@lafcol.lafayette.edu (Andy Dougherty), brian@mathworks.com (Brian Bourgault), imp@village.org (Warner Losh), meissner@cygnus.com (Michael Meissner), rfg@monkeys.com (Ron Guilmette), linux-binutils-in@polstra.com (John Polstra), galenh@micron.net (Galen Hazelwood), ralf@informatik.uni-koblenz.de (Ralf Baechle), linas@linas.org (Linas Vepstas), aries@hal2000.terra.vein.hu (Feher Janos), egcs@egcs.cygnus.com, libc-hacker@sourceware.cygnus.com (GNU C Library), linux-gcc@vger.rutgers.edu (linuxgcc) In-Reply-To: <14251.6461.786461.594860@gargle.gargle.HOWL> from "Wolfgang Wander" at Aug 06, 1999 01:19:57 PM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990806210830.8C18A57BA@ocean.lucon.org> From: hjl@lucon.org (H.J. Lu) > > Ian and H.J., > > here is another problem I ran into - it seems not to be gcc related > as static linking does not trigger the bug. > It works fine for me with binutils 2.9.5.0.5 on Solaris 7/Sparc. H.J. ---- This is the beta release of binutils 2.9.5.0.5 for Linux, which is based on binutils 1999 0806 plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. Please report any bugs related to binutils 2.9.5.0.5 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.5.0.5.tar.gz. Source code. 2. binutils-2.9.5.0.4-2.9.5.0.5.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.5.0.5-1.src.rpm. Source RPM. 4. binutils-2.9.5.0.5-1.i386.rpm. Binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 08/06/99 From gcc-return-8878-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 21:55:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19578 invoked by alias); 6 Aug 1999 21:55:08 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19555 invoked from network); 6 Aug 1999 21:55:04 -0000 Received: from dragonfly.wolfram.com (root@140.177.10.12) by egcs.cygnus.com with SMTP; 6 Aug 1999 21:55:04 -0000 Received: from m.wolfram.com (root@m.wolfram.com [140.177.201.20]) by dragonfly.wolfram.com (8.8.8/8.8.8) with ESMTP id QAA08669; Fri, 6 Aug 1999 16:54:57 -0500 (CDT) Received: from localhost (johnnyb@localhost) by m.wolfram.com (8.9.3/8.9.2) with ESMTP id QAA25340; Fri, 6 Aug 1999 16:52:05 -0500 Date: Fri, 6 Aug 1999 16:52:05 -0500 (CDT) From: Jonathan Bartlett To: scherrey@proteus-tech.com cc: kde-devel@max.tat.physik.uni-tuebingen.de, gcc Subject: Re: Trouble building KDE 1.1.1 under Mandrake 6.0 w/ gcc2.95 In-Reply-To: <37AA90A7.91A6994F@switchco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Not sure, but could this have to do with QT/KDE being C++? Remember that the new GCC does not maintain binary compatibility with C++ libraries compiled with other versions. Therefore, if you compiled any of it with egcs or gcc 2.8 then you would have problems. Jon On Fri, 6 Aug 1999, Benjamin Scherrey wrote: > UPDATED UPDATE - > > I've uninstalled gcc 2.95 leaving behind pgcc-2.91.66 and it seems to > be building just fine. Is this a problem with kde/qt or the new gcc? > > thanx & later, > > Ben Scherrey > > Benjamin Scherrey wrote: > > > > UPDATE - > > > > I've now completely re-installed my system sans qt and kde thinking > > that perhaps old headers where somewhere getting included. No luck. > > Exact same results. Does *anyone* have an idea of what's going > > on?!?!?!? Has anyone built KDE 1.1.1 with gcc 2.95? > > > > please help! > > > > Ben Scherrey > > > > PS: Is this the right list for this question? Let me know if not. > > > > Benjamin Scherrey wrote: > > > > > > OK - it all started when I was trying to build klyx-0.10.0 and it > > > couldn't find some KDE dialog api methods. Figured maybe my KDE was > > > old so I blew it away and the installed QT and attempted to build from > > > source. D/L'd QT1.44, KDE(base&&libs)1.1.1 and got going. QT is in > > > /usr/local/qt and built just fine. I'm running the new release of > > > gcc-2.95 on a Mandrake 6.0 intel linux box. QTDIR is setup correctly > > > and while trying to build KDElibs (at the libtool step constructing > > > libkdecore.la), it complains about all kinds of QT methods being > > > defined twice and changing size! > > > > > > Any ideas? > > > > > > Ben Scherrey > From gcc-return-8879-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 22:41:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22810 invoked by alias); 6 Aug 1999 22:41:11 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22738 invoked from network); 6 Aug 1999 22:40:45 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 6 Aug 1999 22:40:45 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id SAA11799 for ; Fri, 6 Aug 1999 18:40:33 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id SAA24540 for gcc@gcc.gnu.org; Fri, 6 Aug 1999 18:40:31 -0400 (EDT) Date: Fri, 6 Aug 1999 18:40:31 -0400 (EDT) From: John Wehle Message-Id: <199908062240.SAA24540@jwlab.FEITH.COM> To: gcc@gcc.gnu.org Subject: Should dead stores which could trap be deleted? Content-Type: text Consider: long subr(long a, long b) { long c; c = a / b; return 0; } currently gcc produces; pushl %ebp movl %esp,%ebp xorl %eax,%eax leave ret when compiled -O2 on x86 due to dead_trivially_dead_insns. Consider the situation where b equals 0 which on the x86 normally causes a divide by zero exception. What are the guidelines regarding instructions which could trap / to what extent is it valid for optimizations to modify the behaviour of a program with respect to traps? -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-8880-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 23:00:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26153 invoked by alias); 6 Aug 1999 23:00:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26126 invoked from network); 6 Aug 1999 23:00:39 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 6 Aug 1999 23:00:39 -0000 Received: (qmail 15288 invoked by alias); 6 Aug 1999 23:00:37 -0000 Received: (qmail 15281 invoked from network); 6 Aug 1999 23:00:36 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 6 Aug 1999 23:00:36 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id XAA18421; Fri, 6 Aug 1999 23:59:55 +0100 From: Joern Rennecke Message-Id: <199908062259.XAA18421@phal.cygnus.co.uk> Subject: Re: Should dead stores which could trap be deleted? In-Reply-To: <199908062240.SAA24540@jwlab.FEITH.COM> from John Wehle at "Aug 6, 1999 6:40:31 pm" To: john@feith.com (John Wehle) Date: Fri, 6 Aug 1999 23:59:55 +0100 (BST) Cc: gcc@gcc.gnu.org X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > when compiled -O2 on x86 due to dead_trivially_dead_insns. Consider > the situation where b equals 0 which on the x86 normally causes a > divide by zero exception. What are the guidelines regarding instructions > which could trap / to what extent is it valid for optimizations to modify > the behaviour of a program with respect to traps? A division by zero invokes undefined behaviour, hence gcc may do anything it likes with it. From gcc-return-8881-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 23:06:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27597 invoked by alias); 6 Aug 1999 23:06:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27552 invoked from network); 6 Aug 1999 23:06:39 -0000 Received: from palrel3.hp.com (156.153.255.226) by egcs.cygnus.com with SMTP; 6 Aug 1999 23:06:39 -0000 Received: from cllmail.cup.hp.com (cllmail.cup.hp.com [15.28.98.139]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id QAA17375 for ; Fri, 6 Aug 1999 16:06:20 -0700 (PDT) Received: from cup.hp.com (sh750071.cup.hp.com [15.0.98.207]) by cllmail.cup.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS Messaging 5.0) id QAA27937 for ; Fri, 6 Aug 1999 16:06:06 -0700 (PDT) Message-ID: <37AB6A5C.55EC7936@cup.hp.com> Date: Fri, 06 Aug 1999 16:06:04 -0700 From: Dara Hazeghi Reply-To: hazeghi@2xtreme.net X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: GCC 2.95 and floating point precision Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello GCC users, maintainers etc. I recently downloaded and built your gcc2.95 release (Never trusted RPMS anyway) on an i686-pc-linux-gnu. I have a program which demands the full 80bit precision in the Pentium FPU. It's written entirely in C and built and ran fine with gcc2.91.66 (aka egcs 1.1.2). Now however it won't run due to a lack of floating point precision. I am almost certain of this due to the fact that with a similar version of the program only requiring 64bit precision, the calculations work flawleesly (albeit slower). This problem only happens with -O2 or -O3 optimization levels. With -O1 or -O0 I can enable pretty much any other optimizations supported by x86 (including -ffast-math) and the code builds and runs fine. Is there any changes between gcc2.91.66 and gcc2.95 that restricts this use of the Pentium FPU? The program is doing mathematical computation, so I really need the extra 16 bits! Thank for any insight on the topic. On a different topic, is there any way of getting the clobber register asm code that is so deprecated to build on gcc2.95 (maybe --fallow-clobber-registers or something). Yes I know you're supposed to rewrite the code, but what if you can't (I don't know asm). Thanks again. Dara Hazeghi From gcc-return-8882-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 06 23:25:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29701 invoked by alias); 6 Aug 1999 23:25:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29673 invoked from network); 6 Aug 1999 23:25:10 -0000 Received: from newton.math.purdue.edu (root@128.210.3.6) by egcs.cygnus.com with SMTP; 6 Aug 1999 23:25:10 -0000 Received: from polya.math.purdue.edu (lucier@polya.math.purdue.edu [128.210.3.194]) by newton.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.3) with ESMTP id SAA14777; Fri, 6 Aug 1999 18:24:53 -0500 (EST) Received: (from lucier@localhost) by polya.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.1) id SAA00612; Fri, 6 Aug 1999 18:24:49 -0500 (EST) From: Brad Lucier Message-Id: <199908062324.SAA00612@polya.math.purdue.edu> Subject: Re: big slowdown in egcs-1.1.2->gcc-2.95 on alpha To: amylaar@cygnus.co.uk (Joern Rennecke) Date: Fri, 6 Aug 1999 18:24:49 -0500 (EST) Cc: lucier@math.purdue.edu (Brad Lucier), gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, staff@math.purdue.edu, hosking@cs.purdue.edu, wilker@math.purdue.edu, bernds@cygnus.com In-Reply-To: <199908062053.VAA03606@phal.cygnus.co.uk> from "Joern Rennecke" at Aug 06, 1999 09:53:52 PM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I think we could fix this by using pseudo register birth / death lists > instead of complete register sets. That would be nice; here are times comparing egcs-1.1.2 and gcc-2.9.5 on this alpha-ev6 box, without the profiling overhead (0 times have been elided): popov-3% /usr/lib/gcc-lib/alpha-redhat-linux/egcs-2.91.66/cc1 g0-1.i __copysignf copysignf __copysign copysign __fabsf fabsf __fabs fabs __floorf __floor floorf floor __fdimf fdimf __fdim fdim ___H__20_g0_2d_1 ___init_proc ____20_g0_2d_1 time in parse: 10.890208 time in jump: 0.900848 time in flow: 2.382416 time in global-alloc: 10.848240 time in shorten-branch: 0.927200 time in final: 5.018592 time in varconst: 0.007808 popov-4% /export/u10/gcc-2.95/lib/gcc-lib/alphaev6-unknown-linux-gnu/2.95/cc1 g0-1.i __copysignf copysignf __copysign copysign __fabsf fabsf __fabs fabs __floorf __floor floorf floor __fdimf fdimf __fdim fdim ___H__20_g0_2d_1 ___init_proc ____20_g0_2d_1 time in parse: 11.073696 time in jump: 0.923296 time in flow: 3.405264 time in global-alloc: 17.851040 time in shorten-branch: 0.829600 time in final: 5.183536 Brad Lucier lucier@math.purdue.edu From gcc-return-8883-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 01:04:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3854 invoked by alias); 7 Aug 1999 01:03:59 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3839 invoked from network); 7 Aug 1999 01:03:54 -0000 Received: from cantva.canterbury.ac.nz (132.181.30.3) by egcs.cygnus.com with SMTP; 7 Aug 1999 01:03:54 -0000 Received: from CONVERSION-DAEMON by its.canterbury.ac.nz (PMDF V5.2-32 #32514) id <01JEHJF5AY8090OUZU@its.canterbury.ac.nz> for gcc@gcc.gnu.org; Sat, 7 Aug 1999 13:03:52 +1200 (NEW ZEALAND STANDARD TIME) Received: from andromeda.elec.canterbury.ac.nz (andromeda.elec.canterbury.ac.nz [132.181.50.31]) by its.canterbury.ac.nz (PMDF V5.2-32 #32514) with ESMTP id <01JEHJF4YCU290NYVY@its.canterbury.ac.nz>; Sat, 07 Aug 1999 13:03:51 +1200 (NEW ZEALAND STANDARD TIME) Received: from ongaonga.elec.canterbury.ac.nz (ongaonga [132.181.54.69]) by andromeda.elec.canterbury.ac.nz (8.9.3/8.9.3) with ESMTP id NAA15673; Sat, 07 Aug 1999 13:03:43 +1200 (NZST) Received: (from mph@localhost) by ongaonga.elec.canterbury.ac.nz (8.9.3/8.9.3) id MAA09964; Sat, 07 Aug 1999 12:53:59 +1200 Date: Sat, 07 Aug 1999 12:53:59 +1200 (NZST) From: Michael Hayes Subject: Re: Has anyone built gcc-2.95 as a cross for TI c3x/c4x targets? In-reply-to: <37AAFD47.FA9030F2@pentek.com> To: Charles Krug Cc: gcc@gcc.gnu.org Message-id: <14251.32255.280553.891666@ongaonga.elec.canterbury.ac.nz> MIME-version: 1.0 (generated by tm-edit 7.108) X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Content-type: text/plain; charset=US-ASCII References: <199908061457.KAA77444@apache4.btv.ibm.com> <37AAFD47.FA9030F2@pentek.com> Charles Krug writes: > Has anyone built gcc-2.95 as a cross-compiler to TI c3x/c4x targets? > Michael Hayes website seemed to say that 2.95 was going to include > 'c3x/c4x targets. Has this been done yet? Has anyone built it? Yes and yes. It is now included with gcc-2.95 and should build without any problems (you may not be able to build some of the libraries if you don't have C header files previously installed). However, the code produced by gcc-2.95 for the C30/C40 DSPs results in poor benchmark times for the following reasons. 1. It does not emit the fast block repeat instructions. 2. It does not software pipeline loops to utilise parallel instructions. 3. Auto-increment addressing modes are not well utilised. 4. Induction variable combination is poor. 5. Delay slot filling is sub-optimal. To address the first two points, I submitted patches to egcs-patches many months ago that seem to have been piped to /dev/null :-) To address the third point I have written a pass that generates def-use chains that are then scanned for instructions to be combined to utilise auto-increment (and auto-modify) addressing modes. This seems to work well but I do not have the time at present to thoroughly test it. Hopefully Joern will sort out the fourth problem with his work on strength reduction :-) (I still get better strength reduction of induction variables on the C4x with gcc-2.7) Improvements to delay slot filling require large hacks to reorg. This has never worked well with multiple delay slots as the folks working on the SHARC port are also finding. Michael. From gcc-return-8884-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 01:07:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4785 invoked by alias); 7 Aug 1999 01:06:57 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4751 invoked from network); 7 Aug 1999 01:06:50 -0000 Received: from newton.math.purdue.edu (root@128.210.3.6) by egcs.cygnus.com with SMTP; 7 Aug 1999 01:06:50 -0000 Received: from polya.math.purdue.edu (lucier@polya.math.purdue.edu [128.210.3.194]) by newton.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.3) with ESMTP id UAA16138; Fri, 6 Aug 1999 20:06:37 -0500 (EST) Received: (from lucier@localhost) by polya.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.1) id UAA00643; Fri, 6 Aug 1999 20:06:36 -0500 (EST) From: Brad Lucier Message-Id: <199908070106.UAA00643@polya.math.purdue.edu> Subject: Re: big slowdown in egcs-1.1.2->gcc-2.95 on alpha To: amylaar@cygnus.co.uk (Joern Rennecke) Date: Fri, 6 Aug 1999 20:06:35 -0500 (EST) Cc: lucier@math.purdue.edu (Brad Lucier), gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, staff@math.purdue.edu, hosking@cs.purdue.edu, wilker@math.purdue.edu, bernds@cygnus.com In-Reply-To: <199908062053.VAA03606@phal.cygnus.co.uk> from "Joern Rennecke" at Aug 06, 1999 09:53:52 PM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > That's the price we pay for doing register spilling on a per-instruction > basis, and calling compute_use_by_pseudos twice for every instruction > and reload pass. > > I think we could fix this by using pseudo register birth / death lists > instead of complete register sets. > I made a mistake, sorry. I didn't pass the -O1 -fPIC to cc1 when I did the timings; reload is not the problem. Mea culpa. Here are the timings for the various stages of egcs-1.1.2 and gcc-2.95 with -O1 -fPIC. popov-2% /usr/lib/gcc-lib/alpha-redhat-linux/egcs-2.91.66/cc1 -fPIC -O1 g0-1.i __copysignf copysignf __copysign copysign __fabsf fabsf __fabs fabs __floorf __floor floorf floor __fdimf fdimf __fdim fdim ___H__20_g0_2d_1 ___init_proc ____20_g0_2d_1 time in parse: 10.843360 time in integration: 0.007808 time in jump: 7.701616 time in cse: 8.022720 time in loop: 0.046848 time in flow: 2.352160 time in combine: 7.864608 time in local-alloc: 2.923120 time in global-alloc: 4.692608 time in shorten-branch: 0.361120 time in final: 2.023248 popov-4% /export/u10/gcc-2.95/lib/gcc-lib/alphaev6-unknown-linux-gnu/2.95/cc1 -fPIC -O1 g0-1.i __copysignf copysignf __copysign copysign __fabsf fabsf __fabs fabs __floorf __floor floorf floor __fdimf fdimf __fdim fdim ___H__20_g0_2d_1 ___init_proc ____20_g0_2d_1 time in parse: 10.939984 time in integration: 0.000976 time in jump: 8.168144 time in cse: 5.181584 time in loop: 0.039040 time in flow: 2.695712 time in combine: 8.443376 time in local-alloc: 3.038288 time in global-alloc: 119.387248 time in flow2: 2.311168 time in shorten-branch: 0.383568 time in final: 2.120848 You can see there is a big difference in global-alloc. Here is the beginning of the flat composite profile Flat profile: Each sample counts as 0.000976562 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 36.61 57.68 57.68 16 3604.80 3605.63 prune_preferences 12.47 77.32 19.64 391960848 0.00 0.00 bitmap_bit_p 7.29 88.80 11.48 202789 0.06 0.06 record_one_conflict 7.22 100.18 11.38 24 474.20 1233.79 build_insn_chain 1.56 102.64 2.46 8 306.88 19628.50 yyparse 1.35 104.77 2.13 27806760 0.00 0.00 count_pseudo 1.32 106.85 2.08 15315 0.14 0.44 order_regs_for_reload 1.05 108.50 1.65 1436 1.15 1.15 find_reg 0.83 109.82 1.31 2455661 0.00 0.00 yylex The biggest time sink seems to be the quadratic algorithm in prune_preferences in global.c. Again, the complete profile summary is at: http://www.math.purdue.edu/~lucier/gmon.summary.gz Brad Lucier lucier@math.purdue.edu From gcc-return-8885-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 01:32:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8283 invoked by alias); 7 Aug 1999 01:32:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8267 invoked from network); 7 Aug 1999 01:32:39 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 7 Aug 1999 01:32:39 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id VAA13594; Fri, 6 Aug 1999 21:32:37 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id VAA24676; Fri, 6 Aug 1999 21:32:36 -0400 (EDT) Date: Fri, 6 Aug 1999 21:32:36 -0400 (EDT) From: John Wehle Message-Id: <199908070132.VAA24676@jwlab.FEITH.COM> To: amylaar@cygnus.co.uk Subject: Re: Should dead stores which could trap be deleted? Cc: gcc@gcc.gnu.org Content-Type: text >> when compiled -O2 on x86 due to dead_trivially_dead_insns. Consider >> the situation where b equals 0 which on the x86 normally causes a >> divide by zero exception. What are the guidelines regarding instructions >> which could trap / to what extent is it valid for optimizations to modify >> the behaviour of a program with respect to traps? > > A division by zero invokes undefined behaviour, hence gcc may do anything > it likes with it. The routine in question isn't special casing division by zero which I am merely using as an example of something which can trap. Another example is floating point math which also can trap. Interestingly enough may_trap_p does have a specific check for potential division by zero. Can a generalization be made that gcc is free to perform optimizations which eliminates instructions that can trap so long that the resulting code produces the right answer in any situation where the trap would not have occurred? Or is each situation unique and a healthy dose of common sense required? Are traps which are important (and should not "disappear" unexpectedly) indicated in the rtl by using trap_if? -- John PS: At a (very) quick glance I didn't see in rtl.texi where division by zero was stated as being undefined. :-) ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-8886-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 01:48:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9812 invoked by alias); 7 Aug 1999 01:48:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9797 invoked from network); 7 Aug 1999 01:48:52 -0000 Received: from mescaline.gnu.org (158.121.106.21) by egcs.cygnus.com with SMTP; 7 Aug 1999 01:48:52 -0000 Received: from pasanda.cygnus.co.uk (dns.cygnus.co.uk [194.130.39.3]) by mescaline.gnu.org (8.9.1a/8.9.1) with SMTP id VAA02039 for ; Fri, 6 Aug 1999 21:48:50 -0400 Received: (qmail 18686 invoked by alias); 7 Aug 1999 01:47:48 -0000 Received: (qmail 18675 invoked from network); 7 Aug 1999 01:47:48 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 7 Aug 1999 01:47:48 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id CAA18815; Sat, 7 Aug 1999 02:47:06 +0100 From: Joern Rennecke Message-Id: <199908070147.CAA18815@phal.cygnus.co.uk> Subject: Re: Should dead stores which could trap be deleted? In-Reply-To: <199908070132.VAA24676@jwlab.FEITH.COM> from John Wehle at "Aug 6, 1999 9:32:36 pm" To: john@feith.com (John Wehle) Date: Sat, 7 Aug 1999 02:47:06 +0100 (BST) Cc: amylaar@cygnus.co.uk, gcc@gcc.gnu.org X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > PS: At a (very) quick glance I didn't see in rtl.texi where division > by zero was stated as being undefined. :-) It's not in rtl.texi, but in the C standard. However, for floating point you can argue that no undefined behaviour is invoked if NaNs are supported. From gcc-return-8887-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 01:54:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11164 invoked by alias); 7 Aug 1999 01:54:09 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11140 invoked from network); 7 Aug 1999 01:54:05 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 7 Aug 1999 01:54:05 -0000 Received: (qmail 18595 invoked by alias); 7 Aug 1999 01:40:24 -0000 Received: (qmail 18567 invoked from network); 7 Aug 1999 01:40:23 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 7 Aug 1999 01:40:23 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id CAA18804; Sat, 7 Aug 1999 02:39:42 +0100 From: Joern Rennecke Message-Id: <199908070139.CAA18804@phal.cygnus.co.uk> Subject: Re: big slowdown in egcs-1.1.2->gcc-2.95 on alpha In-Reply-To: <199908070106.UAA00643@polya.math.purdue.edu> from Brad Lucier at "Aug 6, 1999 8: 6:35 pm" To: lucier@math.purdue.edu (Brad Lucier) Date: Sat, 7 Aug 1999 02:39:42 +0100 (BST) Cc: amylaar@cygnus.co.uk, lucier@math.purdue.edu, gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, staff@math.purdue.edu, hosking@cs.purdue.edu, wilker@math.purdue.edu, bernds@cygnus.com X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > The biggest time sink seems to be the quadratic algorithm in prune_preferences > in global.c. Hmm, I wonder if the CONFLICT_P tests take a lot of time, or if the rest of the operations in the inner loop cost more. I wonder if this works: Thu Aug 5 22:27:15 1999 J"orn Rennecke * global.c (prune_preferences): Move some invariants out of the inner loop. *** global.c Wed Aug 4 21:33:01 1999 --- global.c-patched Sat Aug 7 02:32:20 1999 *************** prune_preferences () *** 863,869 **** for (i = max_allocno - 1; i >= 0; i--) { ! HARD_REG_SET temp; allocno = allocno_order[i]; COPY_HARD_REG_SET (temp, hard_reg_conflicts[allocno]); --- 863,869 ---- for (i = max_allocno - 1; i >= 0; i--) { ! HARD_REG_SET temp, temp2; allocno = allocno_order[i]; COPY_HARD_REG_SET (temp, hard_reg_conflicts[allocno]); *************** prune_preferences () *** 881,905 **** AND_COMPL_HARD_REG_SET (hard_reg_copy_preferences[allocno], temp); AND_COMPL_HARD_REG_SET (hard_reg_full_preferences[allocno], temp); - CLEAR_HARD_REG_SET (regs_someone_prefers[allocno]); - /* Merge in the preferences of lower-priority registers (they have already been pruned). If we also prefer some of those registers, don't exclude them unless we are of a smaller size (in which case we want to give the lower-priority allocno the first chance for these registers). */ for (j = i + 1; j < max_allocno; j++) if (CONFLICTP (allocno, allocno_order[j]) || CONFLICTP (allocno_order[j], allocno)) { - COPY_HARD_REG_SET (temp, - hard_reg_full_preferences[allocno_order[j]]); if (allocno_size[allocno_order[j]] <= allocno_size[allocno]) ! AND_COMPL_HARD_REG_SET (temp, ! hard_reg_full_preferences[allocno]); ! ! IOR_HARD_REG_SET (regs_someone_prefers[allocno], temp); } } } --- 881,907 ---- AND_COMPL_HARD_REG_SET (hard_reg_copy_preferences[allocno], temp); AND_COMPL_HARD_REG_SET (hard_reg_full_preferences[allocno], temp); /* Merge in the preferences of lower-priority registers (they have already been pruned). If we also prefer some of those registers, don't exclude them unless we are of a smaller size (in which case we want to give the lower-priority allocno the first chance for these registers). */ + CLEAR_HARD_REG_SET (temp); + CLEAR_HARD_REG_SET (temp2); for (j = i + 1; j < max_allocno; j++) if (CONFLICTP (allocno, allocno_order[j]) || CONFLICTP (allocno_order[j], allocno)) { if (allocno_size[allocno_order[j]] <= allocno_size[allocno]) ! IOR_HARD_REG_SET (temp, ! hard_reg_full_preferences[allocno_order[j]]); ! else ! IOR_HARD_REG_SET (temp2, ! hard_reg_full_preferences[allocno_order[j]]); } + AND_COMPL_HARD_REG_SET (temp, hard_reg_full_preferences[allocno]); + IOR_HARD_REG_SET (temp, temp2); + COPY_HARD_REG_SET (regs_someone_prefers[allocno], temp); } } From gcc-return-8888-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 02:51:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14791 invoked by alias); 7 Aug 1999 02:51:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14640 invoked from network); 7 Aug 1999 02:51:46 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 7 Aug 1999 02:51:46 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id XAA21812; Fri, 6 Aug 1999 23:47:39 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id XAA26462; Fri, 6 Aug 1999 23:47:40 -0300 (EST) To: Tom Tromey Cc: java-discuss@sourceware.cygnus.com, gcc@egcs.cygnus.com Cc: gcc-patches@gcc.gnu.org Subject: [fixinc patch] Re: misp-sgi-irix5.2 assembler-preprocessor error building libgcj References: <199907312347.QAA12857@ferrule.cygnus.com.> From: Alexandre Oliva Date: 06 Aug 1999 23:51:25 -0300 In-Reply-To: Tom Tromey's message of "Sat, 31 Jul 1999 16:47:42 -0700" Message-ID: Lines: 23 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= On Jul 31, 1999, Tom Tromey wrote: >>>>>> "Alexandre" == Alexandre Oliva writes: Alexandre> In file included from /home/phd/oliva/src/libgcj-2.95/boehm-gc/mips_sgi_mach_dep.s:2: Alexandre> /usr/include/sys/asm.h:620: unterminated string or character constant Alexandre> oliva@escher% sed -n 620p /usr/include/sys/asm.h Alexandre> # Now we're executing in Kernel Physical (KP) space Alexandre> ^ the culprit > Did you ever get an answer to this? Nope. Here's a patch for gcc. Is this ok to install? Release branch? --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=irix-asm.patch Index: gcc/ChangeLog from Alexandre Oliva * fixinc/inclhack.def: Replace ``We're'' with ``We are'' in IRIX's asm comment. Index: gcc/fixinc/inclhack.def =================================================================== RCS file: /egcs/carton/cvsfiles/egcs/gcc/fixinc/inclhack.def,v retrieving revision 1.33 diff -u -r1.33 inclhack.def --- gcc/fixinc/inclhack.def 1999/08/03 04:06:30 1.33 +++ gcc/fixinc/inclhack.def 1999/08/07 02:47:40 @@ -708,6 +708,20 @@ /* + * IRIX 5.2's contains an asm comment with a contraction + * that causes the assembly preprocessor to complain about an + * unterminated character constant. + */ +fix = { + hackname = irix_asm_apostrophe; + files = sys/asm.h; + + select = "^[ \t]#.*[Ww]e're"; + sed = "s/'/ a/"; +} + + +/* * IRIX 4.0.5 uses struct sockaddr * in prototype without previous definition. */ --=-=-= -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them --=-=-=-- From gcc-return-8889-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 04:28:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21613 invoked by alias); 7 Aug 1999 04:27:59 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21582 invoked from network); 7 Aug 1999 04:27:47 -0000 Received: from newton.math.purdue.edu (root@128.210.3.6) by egcs.cygnus.com with SMTP; 7 Aug 1999 04:27:47 -0000 Received: from polya.math.purdue.edu (lucier@polya.math.purdue.edu [128.210.3.194]) by newton.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.3) with ESMTP id XAA18749; Fri, 6 Aug 1999 23:27:33 -0500 (EST) Received: (from lucier@localhost) by polya.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.1) id XAA00675; Fri, 6 Aug 1999 23:27:32 -0500 (EST) From: Brad Lucier Message-Id: <199908070427.XAA00675@polya.math.purdue.edu> Subject: Re: big slowdown in egcs-1.1.2->gcc-2.95 on alpha To: amylaar@cygnus.co.uk (Joern Rennecke) Date: Fri, 6 Aug 1999 23:27:32 -0500 (EST) Cc: lucier@math.purdue.edu (Brad Lucier), amylaar@cygnus.co.uk, gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, staff@math.purdue.edu, hosking@cs.purdue.edu, wilker@math.purdue.edu, bernds@cygnus.com In-Reply-To: <199908070139.CAA18804@phal.cygnus.co.uk> from "Joern Rennecke" at Aug 07, 1999 02:39:42 AM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > The biggest time sink seems to be the quadratic algorithm in prune_preferences > > in global.c. > > Hmm, I wonder if the CONFLICT_P tests take a lot of time, or if the rest > of the operations in the inner loop cost more. > > I wonder if this works: > Sorry, no, it made little difference: Flat profile: Each sample counts as 0.000976562 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 35.63 55.32 55.32 16 3457.52 3458.44 prune_preferences 12.51 74.75 19.43 391960848 0.00 0.00 bitmap_bit_p 7.40 86.24 11.49 202789 0.06 0.06 record_one_conflict 7.20 97.41 11.17 24 465.58 1218.03 build_insn_chain 1.55 99.83 2.41 8 301.76 19347.54 yyparse 1.49 102.13 2.31 27806760 0.00 0.00 count_pseudo Here are some more details about global_alloc, prune_preferences, and build_insn_chain. ----------------------------------------------- 0.08 99.53 24/24 rest_of_compilation [5] [6] 64.1 0.08 99.53 24 global_alloc [6] 55.32 0.01 16/16 prune_preferences [7] 11.17 18.06 24/24 build_insn_chain [8] 0.24 10.63 24/24 reload [13] 0.12 2.22 16/16 global_conflicts [33] 1.66 0.00 1436/1436 find_reg [39] 0.08 0.01 16/16 expand_preferences [256] 0.00 0.00 24/220059 xmalloc [479] 0.00 0.00 48/5488 get_insns [995] ----------------------------------------------- 55.32 0.01 16/16 global_alloc [6] [7] 35.6 55.32 0.01 16 prune_preferences [7] 0.01 0.00 78844/334068 reg_preferred_class [306] ----------------------------------------------- 11.17 18.06 24/24 global_alloc [6] [8] 18.8 11.17 18.06 24 build_insn_chain [8] 17.40 0.00 350981800/391960848 bitmap_bit_p [9] 0.02 0.43 174187/5402847 note_stores [10] 0.08 0.01 194131/194131 new_insn_chain [263] 0.05 0.00 388262/574314 bitmap_copy [293] 0.04 0.00 574446/16720630 bitmap_set_bit [48] 0.01 0.02 88014/88014 reg_dies [385] 0.00 0.00 34596/3151441 bitmap_clear [204] 0.00 0.00 24/1004613 bitmap_initialize [401] ----------------------------------------------- Brad Lucier lucier@math.purdue.edu From gcc-return-8890-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 06:17:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30581 invoked by alias); 7 Aug 1999 06:17:10 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30566 invoked from network); 7 Aug 1999 06:17:07 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 7 Aug 1999 06:17:07 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id XAA02592; Fri, 6 Aug 1999 23:17:04 -0700 (PDT) Received: by kankakee.wrs.com (SMI-8.6/SMI-SVR4) id XAA25258; Fri, 6 Aug 1999 23:17:04 -0700 Date: Fri, 6 Aug 1999 23:17:04 -0700 From: mrs@wrs.com (Mike Stump) Message-Id: <199908070617.XAA25258@kankakee.wrs.com> To: lucier@math.purdue.edu Subject: Re: big slowdown in egcs-1.1.2->gcc-2.95 on alpha Cc: gcc@gcc.gnu.org > From: Brad Lucier > To: amylaar@cygnus.co.uk (Joern Rennecke) > Date: Fri, 6 Aug 1999 20:06:35 -0500 (EST) > The biggest time sink seems to be the quadratic algorithm in > prune_preferences in global.c. Thanks for pointing out quadratic algorithms... [ blush ] we usually can't win with them, someone always finds _the_ testcase that will kill it. From gcc-return-8891-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 07:46:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5434 invoked by alias); 7 Aug 1999 07:46:53 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5346 invoked by uid 9012); 7 Aug 1999 07:46:29 -0000 Message-ID: <19990807074629.5345.qmail@egcs.cygnus.com> From: korbb@egcs.cygnus.com Subject: RE: [fixinc patch] Re: misp-sgi-irix5.2 assembler-preprocessor error building libgcj To: egcs-patches@egcs.cygnus.com, oliva@dcc.unicamp.br, tromey@cygnus.com, gcc@gcc.gnu.org, autogen@linuxbox.com Date: Sat, 7 Aug 1999 00:46:29 -0700 (PDT) Reply-To: "Bruce Korb" Content-Type: text Alexandre Oliva wrote: > > On Jul 31, 1999, Tom Tromey wrote: > > >>>>>> "Alexandre" == Alexandre Oliva writes: > Alexandre> In file included from /home/phd/oliva/src/libgcj-2.95/boehm-gc/mips_sgi_mach_dep.s:2: > Alexandre> /usr/include/sys/asm.h:620: unterminated string or character constant > > Alexandre> oliva@escher% sed -n 620p /usr/include/sys/asm.h > Alexandre> # Now we're executing in Kernel Physical (KP) space > Alexandre> ^ the culprit > > > Did you ever get an answer to this? > > Nope. Here's a patch for gcc. Is this ok to install? Release > branch? You never got an answer because I never saw the email. Throughout July, email was flaky and I was not 100% on scanning patches & bugs, unless "fixinc" was in the subject. Anyway, there is a problem with it: /* + * IRIX 5.2's contains an asm comment with a contraction + * that causes the assembly preprocessor to complain about an + * unterminated character constant. + */ +fix = { + hackname = irix_asm_apostrophe; + files = sys/asm.h; + + select = "^[ \t]#.*[Ww]e're"; + sed = "s/'/ a/"; +} This fix will select files named "sys/asm.h" that contains a line that starts with either a space or a tab followed by a hash mark followed somewhere on the line by a "[Ww]e're". Once the file is selected, you will replace the first occurrance of every apostorphe with a space and an 'a'. I don't think so. Do you mean this, instead? /* + * IRIX 5.2's contains an asm comment with a contraction + * that causes the assembly preprocessor to complain about an + * unterminated character constant. + */ +fix = { + hackname = irix_asm_apostrophe; + files = sys/asm.h; + + select = "^[ \t]*#.*[Ww]e're"; + sed = "/^[ \t]*#/s/\\([Ww]e\\)'re/\\1 are/"; +} From gcc-return-8892-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 08:04:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9025 invoked by alias); 7 Aug 1999 08:04:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8978 invoked from network); 7 Aug 1999 08:04:14 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 7 Aug 1999 08:04:14 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id BAA06887; Sat, 7 Aug 1999 01:04:14 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id BAA12354; Sat, 7 Aug 1999 01:04:14 -0700 Date: Sat, 7 Aug 1999 01:04:14 -0700 From: Richard Henderson To: Brad Lucier Cc: Joern Rennecke , gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, staff@math.purdue.edu, hosking@cs.purdue.edu, wilker@math.purdue.edu, bernds@cygnus.com, gcc-patches@gcc.gnu.org Subject: Re: big slowdown in egcs-1.1.2->gcc-2.95 on alpha Message-ID: <19990807010414.A25476@cygnus.com> References: <199908070139.CAA18804@phal.cygnus.co.uk> <199908070427.XAA00675@polya.math.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199908070427.XAA00675@polya.math.purdue.edu>; from Brad Lucier on Fri, Aug 06, 1999 at 11:27:32PM -0500 On Fri, Aug 06, 1999 at 11:27:32PM -0500, Brad Lucier wrote: > Each sample counts as 0.000976562 seconds. > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 35.63 55.32 55.32 16 3457.52 3458.44 prune_preferences > 12.51 74.75 19.43 391960848 0.00 0.00 bitmap_bit_p The following should kill bitmap_bit_p from the interesting functions. r~ * global.c (build_insn_chain): Use EXECUTE_IF_SET_IN_REG_SET to invert loops. Simplify block scanning. Index: global.c =================================================================== RCS file: /egcs/carton/cvsfiles/egcs/gcc/global.c,v retrieving revision 1.28 diff -u -p -d -r1.28 global.c --- global.c 1999/08/04 07:50:08 1.28 +++ global.c 1999/08/07 07:58:44 @@ -271,7 +271,7 @@ static void set_preference PROTO((rtx, r static void dump_conflicts PROTO((FILE *)); static void reg_becomes_live PROTO((rtx, rtx)); static void reg_dies PROTO((int, enum machine_mode)); -static void build_insn_chain PROTO((rtx)); +static void build_insn_chain PROTO((void)); /* Perform allocation of pseudo-registers not allocated by local_alloc. FILE is a file to output debugging information on, @@ -578,7 +578,7 @@ global_alloc (file) if (n_basic_blocks > 0) #endif { - build_insn_chain (get_insns ()); + build_insn_chain (); retval = reload (get_insns (), 1, file); } @@ -1667,96 +1667,88 @@ reg_dies (regno, mode) /* Walk the insns of the current function and build reload_insn_chain, and record register life information. */ static void -build_insn_chain (first) - rtx first; +build_insn_chain () { struct insn_chain **p = &reload_insn_chain; struct insn_chain *prev = 0; - int b = 0; + int b; live_relevant_regs = ALLOCA_REG_SET (); - for (; first; first = NEXT_INSN (first)) + for (b = n_basic_blocks - 1; b >= 0; --b) { - struct insn_chain *c; - - if (first == BLOCK_HEAD (b)) - { - int i; - CLEAR_REG_SET (live_relevant_regs); - for (i = 0; i < FIRST_PSEUDO_REGISTER; i++) - if (REGNO_REG_SET_P (BASIC_BLOCK (b)->global_live_at_start, i) - && ! TEST_HARD_REG_BIT (eliminable_regset, i)) - SET_REGNO_REG_SET (live_relevant_regs, i); + basic_block bb = BASIC_BLOCK (b); + rtx insn, end; + int i; - for (; i < max_regno; i++) - if (reg_renumber[i] >= 0 - && REGNO_REG_SET_P (BASIC_BLOCK (b)->global_live_at_start, i)) - SET_REGNO_REG_SET (live_relevant_regs, i); - } + CLEAR_REG_SET (live_relevant_regs); - if (GET_CODE (first) != NOTE && GET_CODE (first) != BARRIER) + EXECUTE_IF_SET_IN_REG_SET (bb->global_live_at_start, 0, i, { - c = new_insn_chain (); - c->prev = prev; - prev = c; - *p = c; - p = &c->next; - c->insn = first; - c->block = b; + if ((i < FIRST_PSEUDO_REGISTER + && ! TEST_HARD_REG_BIT (eliminable_regset, i)) + || (i >= FIRST_PSEUDO_REGISTER + && reg_renumber[i] >= 0)) + SET_REGNO_REG_SET (live_relevant_regs, i); + }); - COPY_REG_SET (c->live_before, live_relevant_regs); + insn = bb->head, end = bb->end; + while (1) + { + struct insn_chain *c; - if (GET_RTX_CLASS (GET_CODE (first)) == 'i') + if (GET_CODE (insn) != NOTE) { - rtx link; - - /* Mark the death of everything that dies in this instruction. */ + c = new_insn_chain (); + c->prev = prev; + prev = c; + *p = c; + p = &c->next; + c->insn = insn; + c->block = b; - for (link = REG_NOTES (first); link; link = XEXP (link, 1)) - if (REG_NOTE_KIND (link) == REG_DEAD - && GET_CODE (XEXP (link, 0)) == REG) - reg_dies (REGNO (XEXP (link, 0)), GET_MODE (XEXP (link, 0))); + COPY_REG_SET (c->live_before, live_relevant_regs); - /* Mark everything born in this instruction as live. */ + if (GET_RTX_CLASS (GET_CODE (insn)) == 'i') + { + rtx link; - note_stores (PATTERN (first), reg_becomes_live); - } + /* Mark the death of everything that dies in this + instruction. */ + for (link = REG_NOTES (insn); link; link = XEXP (link, 1)) + if (REG_NOTE_KIND (link) == REG_DEAD + && GET_CODE (XEXP (link, 0)) == REG) + reg_dies (REGNO (XEXP (link, 0)), + GET_MODE (XEXP (link, 0))); - /* Remember which registers are live at the end of the insn, before - killing those with REG_UNUSED notes. */ - COPY_REG_SET (c->live_after, live_relevant_regs); + /* Mark everything born in this instruction as live. */ + note_stores (PATTERN (insn), reg_becomes_live); + } - if (GET_RTX_CLASS (GET_CODE (first)) == 'i') - { - rtx link; + /* Remember which registers are live at the end of the insn, + before killing those with REG_UNUSED notes. */ + COPY_REG_SET (c->live_after, live_relevant_regs); - /* Mark anything that is set in this insn and then unused as dying. */ + if (GET_RTX_CLASS (GET_CODE (insn)) == 'i') + { + rtx link; - for (link = REG_NOTES (first); link; link = XEXP (link, 1)) - if (REG_NOTE_KIND (link) == REG_UNUSED - && GET_CODE (XEXP (link, 0)) == REG) - reg_dies (REGNO (XEXP (link, 0)), GET_MODE (XEXP (link, 0))); + /* Mark anything that is set in this insn and then unused + as dying. */ + for (link = REG_NOTES (insn); link; link = XEXP (link, 1)) + if (REG_NOTE_KIND (link) == REG_UNUSED + && GET_CODE (XEXP (link, 0)) == REG) + reg_dies (REGNO (XEXP (link, 0)), + GET_MODE (XEXP (link, 0))); + } } - } - - if (first == BLOCK_END (b)) - b++; - /* Stop after we pass the end of the last basic block. Verify that - no real insns are after the end of the last basic block. - - We may want to reorganize the loop somewhat since this test should - always be the right exit test. */ - if (b == n_basic_blocks) - { - for (first = NEXT_INSN (first) ; first; first = NEXT_INSN (first)) - if (GET_RTX_CLASS (GET_CODE (first)) == 'i' - && GET_CODE (PATTERN (first)) != USE) - abort (); - break; + if (insn == end) + break; + insn = NEXT_INSN (insn); } } + FREE_REG_SET (live_relevant_regs); *p = 0; } From gcc-return-8893-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 08:07:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10712 invoked by alias); 7 Aug 1999 08:07:02 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10663 invoked from network); 7 Aug 1999 08:06:59 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 7 Aug 1999 08:06:59 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id FAA24098; Sat, 7 Aug 1999 05:02:53 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id FAA18565; Sat, 7 Aug 1999 05:02:52 -0300 (EST) To: "Bruce Korb" Cc: egcs-patches@egcs.cygnus.com, tromey@cygnus.com, gcc@gcc.gnu.org, autogen@linuxbox.com Subject: Re: [fixinc patch] Re: misp-sgi-irix5.2 assembler-preprocessor error building libgcj References: <19990807074629.5345.qmail@egcs.cygnus.com> From: Alexandre Oliva Date: 07 Aug 1999 05:06:45 -0300 In-Reply-To: korbb@egcs.cygnus.com's message of "Sat, 7 Aug 1999 00:46:29 -0700 (PDT)" Message-ID: Lines: 18 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 7, 1999, korbb@egcs.cygnus.com wrote: > Once the file is selected, you will replace the first occurrance > of every apostorphe with a space and an 'a'. I don't think so. Weird... I could swear I had posted a followup with a fix for that problem, but I can't find it any more :-( Anyway, your fix is much better than mine. If Jeff approves it for the release branch, would you please take care of installing it? (I'm not sure I have the right versions of the tools to generate the fixinc sources/scripts) -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-8894-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 09:05:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24370 invoked by alias); 7 Aug 1999 09:04:58 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24352 invoked from network); 7 Aug 1999 09:04:54 -0000 Received: from custos.foa.se (HELO mercur.foa.se) (150.227.16.253) by egcs.cygnus.com with SMTP; 7 Aug 1999 09:04:54 -0000 Received: from hobbe.lin.foa.se (hobbe.lin.foa.se [150.227.33.76]) by mercur.foa.se (8.9.3/8.9.3) with SMTP id LAA02245; Sat, 7 Aug 1999 11:04:50 +0200 (MET DST) Received: from arnljot.lin.foa.se by hobbe.lin.foa.se (SMI-8.6/SMI-SVR4) id LAA20028; Sat, 7 Aug 1999 11:04:17 +0200 Received: from arnljot.lin.foa.se (IDENT:chj@localhost [127.0.0.1]) by arnljot.lin.foa.se (8.9.3/8.9.3) with ESMTP id NAA21566; Sat, 7 Aug 1999 13:04:48 +0200 Message-Id: <199908071104.NAA21566@arnljot.lin.foa.se> X-Mailer: exmh version 2.0.2 To: gcc@gcc.gnu.org Cc: "H.J. Lu" Subject: gcc-2.95 matlab mex cross-compiler (to libc5 from libc6) From: Christian =?iso-8859-1?Q?J=F6nsson?= FOA 72 X-face: 2tQjSw>|IA680lA7r'G9Y[jfoS>tTPw4-B#mQo_C+{6>^DWZP`o.h libXpm.so.4.= 9* -rwxr-xr-x 1 106 62748 Oct 15 1998 libXpm.so.4.9* lrwxrwxrwx 1 root 14 May 24 20:22 libc.so.5 -> libc.so.5.4.38= * -rwxr-xr-x 1 106 1849257 Sep 27 1998 libc.so.5.4.38* lrwxrwxrwx 1 root 16 May 24 20:22 libg++.so.27 -> libg++.so.2= 7.2.8* -rwxr-xr-x 1 106 969891 Sep 27 1998 libg++.so.27.2.8* lrwxrwxrwx 1 root 13 May 24 20:22 libm.so.5 -> libm.so.5.0.9*= -rwxr-xr-x 1 106 75717 Sep 27 1998 libm.so.5.0.9* lrwxrwxrwx 1 root 19 May 24 20:22 libstdc++.so.27 -> libstdc+= +.so.27.2.8* -rwxr-xr-x 1 106 875636 Sep 27 1998 libstdc++.so.27.2.8* [chj@arnljot paper]$ = Now, I don't know if you're familiar with matlab but there's an important= = feature of matlab and that is mex. This means that one can compile C/C++/F77 source code into a dynamically loaded (by the matlab exe) code.= But, this means that when compiling and linking that mex code, one has to= use some kind of cross-compiler/linker under a glibc based linux system. The subject is a little explained at http://www.mathworks.com/support/solutions/v5/11129.shtml but... OK, there are some rpm's available for that as ftp://ftp.redhat.com/contrib/libc6/i386/gcc-libc5-2.7.2.3-1.i386.rpm ftp://ftp.redhat.com/contrib/libc6/i386/gcc-libc5-c++-2.7.2.3-1.i386.rpm ftp://ftp.redhat.com/contrib/libc6/i386/libc5-5.4.38-3.i386.rpm ftp://ftp.redhat.com/contrib/libc6/i386/libc5-devel-5.4.38-3.i386.rpm but I can't find any src rpm for gcc-libc5... Now, I would very much like to see a gcc-2.95 based system for this, ie, = build replacements for gcc-libc5-2.7.2.3, gcc-libc5-c++-2.7.2.3, and also= = add in gcc-libc5-g77-2.95 that are all based on gcc-2.95 (as cross-compil= er/ linker)... So, do you have any hints on how to proceed? Would you perhaps help me in= = doing so? Do you have any pointers to useful information in this subjetc?= I need plenty of guidance on both gcc-2.95/RHL 6.0 and = cross-compiler/linker of gcc-libc5-2.95. I can test compile the gcc-libc = stuff and then test to compile some linux matlab mex examples. TIA for any comments, /ChJ From gcc-return-8895-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 11:05:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1425 invoked by alias); 7 Aug 1999 11:04:58 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1409 invoked from network); 7 Aug 1999 11:04:51 -0000 Received: from socks.k-net.dtu.dk (HELO k4315.kampsax.dtu.dk) (130.225.71.228) by egcs.cygnus.com with SMTP; 7 Aug 1999 11:04:51 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by k4315.kampsax.dtu.dk with SMTP; 7 Aug 1999 11:03:42 -0000 Date: 07 Aug 99 11:25:49 +0100 From: "Rask Ingemann Lambertsen" Subject: Re: Should dead stores which could trap be deleted? To: "EGCS mailing list" In-Reply-To: <199908070132.VAA24676@jwlab.FEITH.COM> Message-ID: <1071.888T2481T6855093@kampsax.k-net.dk> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Organization: Me? Organised? Dream on... X-Files: The truth is out there. X-Mailer: THOR 2.5a (Amiga;TCP/IP) Den 07-Aug-99 02:32:36 skrev John Wehle følgende om "Re: Should dead stores which could trap be deleted?": > The routine in question isn't special casing division by zero which > I am merely using as an example of something which can trap. Another > example is floating point math which also can trap. Interestingly enough > may_trap_p does have a specific check for potential division by zero. Another example that may trap is int fubar (void) { long c; c = 42; return (0); } if you happen to run out of stack space at that point. GCC happily optimises such a store away, if I'm not mistaken. Regards, /¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | | Please Tell Me if you Don't Get This Message | From gcc-return-8896-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 12:28:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18290 invoked by alias); 7 Aug 1999 12:28:22 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18174 invoked from network); 7 Aug 1999 12:28:09 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 7 Aug 1999 12:28:09 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id OAA15616; Sat, 7 Aug 1999 14:27:20 +0200 Message-ID: <37AC2628.C9F3174B@moene.indiv.nluug.nl> Date: Sat, 07 Aug 1999 14:27:20 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: hazeghi@2xtreme.net CC: gcc@gcc.gnu.org Subject: Re: GCC 2.95 and floating point precision References: <37AB6A5C.55EC7936@cup.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dara Hazeghi wrote: > I recently downloaded and built your gcc2.95 release (Never trusted RPMS > anyway) on an i686-pc-linux-gnu. I have a program which demands the full > 80bit precision in the Pentium FPU. It's written entirely in C and built > and ran fine with gcc2.91.66 (aka egcs 1.1.2). Now however it won't run > due to a lack of floating point precision. I am almost certain of this > due to the fact that with a similar version of the program only > requiring 64bit precision, the calculations work flawleesly (albeit > slower). This problem only happens with -O2 or -O3 optimization levels. > With -O1 or -O0 I can enable pretty much any other optimizations > supported by x86 (including -ffast-math) and the code builds and runs > fine. Is there any changes between gcc2.91.66 and gcc2.95 that restricts > this use of the Pentium FPU? The program is doing mathematical > computation, so I really need the extra 16 bits! Thank for any insight > on the topic. Well, I'm not a C guru, but I get from the above that you have two versions of your program, one with all floating point variables and arrays declared `long double' and another with all of them declared `double' - is that correct ? The `double' variant seems to work OK when compiled with gcc-2.95 and the `long double' variant does not ? I do not think any change in gcc-2.95 w.r.t. egcs-1.1.2 was _meant_ to introduce a change in floating point arithmetic, so the behaviour you're seeing might well point to a bug. Could you supply: 1. The failing source in question (with input and _expected_ output) 2. The options given to gcc when compiling it that lead to the failing executable 3. [Optional] the extra option in addition to -O1 which makes the executable fail ? > On a different topic, is there any way of getting the clobber register > asm code that is so deprecated to build on gcc2.95 (maybe > --fallow-clobber-registers or something). Yes I know you're supposed to > rewrite the code, but what if you can't (I don't know asm). Thanks > again. The only way to compile that code is to use egcs-1.1.2 - At Your Own Risk [it doesn't have a well-defined meaning]. HTH, -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-8897-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 14:26:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2198 invoked by alias); 7 Aug 1999 14:26:20 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2180 invoked from network); 7 Aug 1999 14:26:12 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 7 Aug 1999 14:26:12 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id QAA19612 for ; Sat, 7 Aug 1999 16:25:32 +0200 Message-ID: <37AC41DB.54294F99@moene.indiv.nluug.nl> Date: Sat, 07 Aug 1999 16:25:31 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Help! Is there a C++ doctor in the audience ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I updated my local 2.95 repository at around 12 UTC today. Unfortunately, I get: /home/toon/compilers/releases/obj/gcc/xgcc -B/home/toon/compilers/releases/obj/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -c -g -O2 -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates -I. -I../../../egcs/libio -nostdinc++ -D_IO_MTSAFE_IO ../../../egcs/libio/iomanip.cc In file included from ../../../egcs/libio/iomanip.cc:29: ../../../egcs/libio/iomanip.h:65: non-template type `smanip' used as a template ../../../egcs/libio/iomanip.h:65: ANSI C++ forbids declaration `m' with no type ../../../egcs/libio/iomanip.h:67: non-template type `smanip' used as a template ../../../egcs/libio/iomanip.h:67: ANSI C++ forbids declaration `m' with no type ../../../egcs/libio/iomanip.h: In instantiation of `smanip': ../../../egcs/libio/iomanip.h:71: instantiated from here ../../../egcs/libio/iomanip.h:67: template-id `operator <<<>' for `operator <<(ostream &, const int &)' does not match any template declaration ../../../egcs/libio/iomanip.h:65: template-id `operator >><>' for `operator >>(istream &, const int &)' does not match any template declaration ../../../egcs/libio/iomanip.h: In instantiation of `smanip': ../../../egcs/libio/iomanip.h:72: instantiated from here ../../../egcs/libio/iomanip.h:67: template-id `operator <<<>' for `operator <<(ostream &, const int &)' does not match any template declaration ../../../egcs/libio/iomanip.h:65: template-id `operator >><>' for `operator >>(istream &, const int &)' does not match any template declaration ../../../egcs/libio/iomanip.h:119: non-template type `imanip' used as a template ../../../egcs/libio/iomanip.h:119: ANSI C++ forbids declaration `m' with no type ../../../egcs/libio/iomanip.h:151: non-template type `omanip' used as a template ../../../egcs/libio/iomanip.h:151: ANSI C++ forbids declaration `m' with no type ../../../egcs/libio/iomanip.h: In function `class istream & operator >>(istream &, const smanip &)': ../../../egcs/libio/iomanip.cc:87: instantiated from here ../../../egcs/libio/iomanip.h:60: `int smanip::_a' is private ../../../egcs/libio/iomanip.h:77: within this context ../../../egcs/libio/iomanip.h:59: `class ios & (* smanip::_f)(ios &, int)' is private ../../../egcs/libio/iomanip.h:77: within this context ../../../egcs/libio/iomanip.h: In function `class istream & operator >><__fmtflags>(istream &, const smanip &)': ../../../egcs/libio/iomanip.cc:88: instantiated from here ../../../egcs/libio/iomanip.h:60: `__fmtflags smanip::_a' is private ../../../egcs/libio/iomanip.h:77: within this context ../../../egcs/libio/iomanip.h:59: `class ios & (* smanip::_f)(ios &, long unsigned int)' is private ../../../egcs/libio/iomanip.h:77: within this context ../../../egcs/libio/iomanip.h: In function `class ostream & operator <<(ostream &, const smanip &)': ../../../egcs/libio/iomanip.cc:89: instantiated from here ../../../egcs/libio/iomanip.h:60: `int smanip::_a' is private ../../../egcs/libio/iomanip.h:81: within this context ../../../egcs/libio/iomanip.h:59: `class ios & (* smanip::_f)(ios &, int)' is private ../../../egcs/libio/iomanip.h:81: within this context ../../../egcs/libio/iomanip.h: In function `class ostream & operator <<<__fmtflags>(ostream &, const smanip &)': ../../../egcs/libio/iomanip.cc:90: instantiated from here ../../../egcs/libio/iomanip.h:60: `__fmtflags smanip::_a' is private ../../../egcs/libio/iomanip.h:81: within this context ../../../egcs/libio/iomanip.h:59: `class ios & (* smanip::_f)(ios &, long unsigned int)' is private ../../../egcs/libio/iomanip.h:81: within this context make[2]: *** [iomanip.o] Error 1 when building libio. Anyone who knows what's wrong here ? TIA, -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html Wait until we rewrite libf2c in Fortran ... From gcc-return-8898-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 14:38:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3336 invoked by alias); 7 Aug 1999 14:38:02 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3239 invoked from network); 7 Aug 1999 14:37:30 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 7 Aug 1999 14:37:30 -0000 Received: from bolero.cs.tu-berlin.de (doko@bolero.cs.tu-berlin.de [130.149.19.1]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id QAA06915 for ; Sat, 7 Aug 1999 16:33:03 +0200 (MET DST) Received: (from doko@localhost) by bolero.cs.tu-berlin.de (8.9.1/8.9.0) id QAA28055; Sat, 7 Aug 1999 16:33:02 +0200 (MET DST) From: Matthias Klose MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 7 Aug 1999 16:33:02 +0200 (MET DST) To: gcc@gcc.gnu.org Subject: cpp: handling of DOS newlines after line continuation backslashes? X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14252.17061.306678.337780@bolero> How is cpp supposed to handle DOS newlines after line continuation backslashes on a *nix platform? #define a(b) (b*\^M b) main() {printf("%d\n", a(5));} $ gcc foo.c foo.c:2: parse error before `)' foo.c:3: stray '\' in program ^M denotes the char with ASCII code 13. Without this char it works like it should. $ gcc -E foo.c # 1 "foo.c" b) main() {printf("%d\n", ( 5 *\ );} From gcc-return-8899-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 14:48:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4486 invoked by alias); 7 Aug 1999 14:48:32 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4470 invoked from network); 7 Aug 1999 14:48:28 -0000 Received: from mandrakesoft.mandrakesoft.com (216.71.84.35) by egcs.cygnus.com with SMTP; 7 Aug 1999 14:48:28 -0000 Received: from vador.mandrakesoft.com (dyn-1-1-125.Vin.dialup.oleane.fr [195.25.4.125]) by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with ESMTP id JAA11437; Sat, 7 Aug 1999 09:46:01 -0500 Received: (from chmou@localhost) by vador.mandrakesoft.com (8.9.3/8.9.3/Chmouel/SMTP) id QAA09194; Sat, 7 Aug 1999 16:47:22 +0200 To: kde-devel@kde.org Cc: scherrey@proteus-tech.com, kde-devel@max.tat.physik.uni-tuebingen.de, gcc Subject: Re: Trouble building KDE 1.1.1 under Mandrake 6.0 w/ gcc2.95 References: X-no-archive: yes From: Chmouel Boudjnah Date: 07 Aug 1999 16:47:22 +0200 In-Reply-To: Jonathan Bartlett's message of "Fri, 6 Aug 1999 16:52:05 -0500 (CDT)" Message-ID: <877ln7wsud.fsf@vador.mandrakesoft.com> Lines: 49 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Jonathan Bartlett writes: > Not sure, but could this have to do with QT/KDE being C++? Remember that > the new GCC does not maintain binary compatibility with C++ libraries > compiled with other versions. Therefore, if you compiled any of it with > egcs or gcc 2.8 then you would have problems. Humm last changelog from cooker distribution(*) : --=-=-= From: ChangeLog Automate Subject: [CHRPM] NAME: kdelibs VER: 1.1.1.99_19990807 REL: 1mdk To: Changelog List Date: Sat, 7 Aug 1999 09:25 -0500 --=-=-= Name : kdelibs Distribution: Mandrake Version : 1.1.1.99_19990807 Vendor: MandrakeSoft Release : 1mdk Build Date: Sat Aug 07 07:31:21 1999 Install date: (not installed) Build Host: locutus.mandrakesoft.de Group : System Environment/Libraries Source RPM: (none) Size : 1055912 Summary : K Desktop Environment - Libraries Description : Libraries for the K Desktop Environment: KDE Libraries included: kdecore (KDE core library), kdeui (user interface), kfm (file manager), khtmlw (HTML widget), kfile (file access), kspell (spelling checker), jscript (javascript), kab (addressbook), kimgio (image manipulation), mediatool (sound, mixing and animation). --=-=-= Last Changelog: * Fri Aug 06 1999 Bernhard Rosenkraenzer - fix building with {p,}gcc 2.95 -- See http://www.linux-mandrake.com/cooker/ for lists of mirrors --=-=-= it's fixed by bero. (*): http://www.linux-mandrake.com/cooker/ -- MandrakeSoft http://www.mandrakesoft.com/ --Chmouel From gcc-return-8900-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 15:05:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5821 invoked by alias); 7 Aug 1999 15:04:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5800 invoked from network); 7 Aug 1999 15:04:41 -0000 Received: from cg667526-a.adubn1.nj.home.com (HELO drow.them.org) (mail@24.2.213.175) by egcs.cygnus.com with SMTP; 7 Aug 1999 15:04:41 -0000 Received: from drow by drow.them.org with local (Exim 3.02 #1 (Debian)) id 11D84A-0002pR-00; Sat, 07 Aug 1999 11:07:22 -0400 Date: Sat, 7 Aug 1999 11:07:22 -0400 From: Daniel Jacobowitz To: gcc@gcc.gnu.org Subject: [C++] Overloading a type name with a function Message-ID: <19990807110722.A10855@them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.12i I have this testcase, which compiled under egcs 1.1.2: --------- class A {}; class B { protected: bool A(int a); }; class C : public B { A myA; }; --------- >From what I can tell the definition of 'class A' is completely hidden in C by 'bool B::A(int)'. Thus a syntax error in the declaration of myA. Is this right, or should the compiler find the class A declaration in the top level? Dan /--------------------------------\ /--------------------------------\ | Daniel Jacobowitz |__| SCS Class of 2002 | | Debian GNU/Linux Developer __ Carnegie Mellon University | | dan@debian.org | | dmj+@andrew.cmu.edu | \--------------------------------/ \--------------------------------/ From gcc-return-8901-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 15:08:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6774 invoked by alias); 7 Aug 1999 15:08:05 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6730 invoked from network); 7 Aug 1999 15:08:01 -0000 Received: from newton.math.purdue.edu (root@128.210.3.6) by egcs.cygnus.com with SMTP; 7 Aug 1999 15:08:01 -0000 Received: from polya.math.purdue.edu (lucier@polya.math.purdue.edu [128.210.3.194]) by newton.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.3) with ESMTP id KAA28106; Sat, 7 Aug 1999 10:07:56 -0500 (EST) Received: (from lucier@localhost) by polya.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.1) id KAA01061; Sat, 7 Aug 1999 10:07:55 -0500 (EST) From: Brad Lucier Message-Id: <199908071507.KAA01061@polya.math.purdue.edu> Subject: Re: big slowdown in egcs-1.1.2->gcc-2.95 on alpha To: rth@cygnus.com (Richard Henderson) Date: Sat, 7 Aug 1999 10:07:55 -0500 (EST) Cc: lucier@math.purdue.edu (Brad Lucier), amylaar@cygnus.co.uk (Joern Rennecke), gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, staff@math.purdue.edu, hosking@cs.purdue.edu, wilker@math.purdue.edu, bernds@cygnus.com, gcc-patches@gcc.gnu.org In-Reply-To: <19990807010414.A25476@cygnus.com> from "Richard Henderson" at Aug 07, 1999 01:04:14 AM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > The following should kill bitmap_bit_p from the interesting > functions. I'm leaving town in about an hour, and won't be able to test this patch until I get e-mail access or I get back on the 16th. The *.i files I'm using to test 'cc1 -fPIC -O1' are at http://www.math.purdue.edu/~lucier/testcases.tar.gz in case anyone else wants to try them. Brad Lucier lucier@math.purdue.edu From gcc-return-8902-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 15:11:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8355 invoked by alias); 7 Aug 1999 15:11:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8340 invoked from network); 7 Aug 1999 15:11:44 -0000 Received: from trans.germany.net (151.189.0.16) by egcs.cygnus.com with SMTP; 7 Aug 1999 15:11:44 -0000 Received: from picard.mandrakesoft.de (kde@picard.mandrakesoft.de [151.189.96.131]) by trans.germany.net (8.8.8/8.8.8) with ESMTP id RAA03377; Sat, 7 Aug 1999 17:11:24 +0200 (MET DST) Date: Sat, 7 Aug 1999 17:13:20 +0200 (CEST) From: Bernhard Rosenkraenzer To: kde-devel@kde.org cc: scherrey@proteus-tech.com, kde-devel@max.tat.physik.uni-tuebingen.de, gcc Subject: Re: Trouble building KDE 1.1.1 under Mandrake 6.0 w/ gcc2.95 In-Reply-To: <877ln7wsud.fsf@vador.mandrakesoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 7 Aug 1999, Chmouel Boudjnah wrote: > Jonathan Bartlett writes: > > > Not sure, but could this have to do with QT/KDE being C++? Remember that > > the new GCC does not maintain binary compatibility with C++ libraries > > compiled with other versions. Therefore, if you compiled any of it with > > egcs or gcc 2.8 then you would have problems. > > Humm last changelog from cooker distribution(*) : > - fix building with {p,}gcc 2.95 No need to look for any patches - I've already commited them to KDE CVS. LLaP bero From gcc-return-8903-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 15:27:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9718 invoked by alias); 7 Aug 1999 15:27:20 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9671 invoked from network); 7 Aug 1999 15:27:16 -0000 Received: from newton.math.purdue.edu (root@128.210.3.6) by egcs.cygnus.com with SMTP; 7 Aug 1999 15:27:16 -0000 Received: from polya.math.purdue.edu (lucier@polya.math.purdue.edu [128.210.3.194]) by newton.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.3) with ESMTP id KAA28328; Sat, 7 Aug 1999 10:27:11 -0500 (EST) Received: (from lucier@localhost) by polya.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.1) id KAA01084; Sat, 7 Aug 1999 10:27:11 -0500 (EST) From: Brad Lucier Message-Id: <199908071527.KAA01084@polya.math.purdue.edu> Subject: Re: big slowdown in egcs-1.1.2->gcc-2.95 on alpha To: rth@cygnus.com (Richard Henderson) Date: Sat, 7 Aug 1999 10:27:11 -0500 (EST) Cc: lucier@math.purdue.edu (Brad Lucier), amylaar@cygnus.co.uk (Joern Rennecke), gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, staff@math.purdue.edu, hosking@cs.purdue.edu, wilker@math.purdue.edu, bernds@cygnus.com, gcc-patches@gcc.gnu.org In-Reply-To: <19990807010414.A25476@cygnus.com> from "Richard Henderson" at Aug 07, 1999 01:04:14 AM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > On Fri, Aug 06, 1999 at 11:27:32PM -0500, Brad Lucier wrote: > > Each sample counts as 0.000976562 seconds. > > % cumulative self self total > > time seconds seconds calls ms/call ms/call name > > 35.63 55.32 55.32 16 3457.52 3458.44 prune_preferences > > 12.51 74.75 19.43 391960848 0.00 0.00 bitmap_bit_p > > The following should kill bitmap_bit_p from the interesting > functions. Right on ... Flat profile: Each sample counts as 0.000976562 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 44.25 56.94 56.94 16 3558.59 3559.59 prune_preferences 8.93 68.43 11.49 202789 0.06 0.06 record_one_conflict 2.05 71.07 2.64 40979048 0.00 0.00 bitmap_bit_p 1.88 73.49 2.42 8 303.10 16018.62 yyparse 1.67 75.65 2.15 27806760 0.00 0.00 count_pseudo 1.58 77.68 2.03 15315 0.13 0.47 order_regs_for_reload Brad Lucier lucier@math.purdue.edu From gcc-return-8904-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 16:53:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15429 invoked by alias); 7 Aug 1999 16:53:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15409 invoked from network); 7 Aug 1999 16:53:38 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 7 Aug 1999 16:53:38 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id JAA12273; Sat, 7 Aug 1999 09:45:26 -0700 Message-Id: <199908071645.JAA12273@zack.bitmover.com> To: Matthias Klose cc: gcc@gcc.gnu.org Subject: Re: cpp: handling of DOS newlines after line continuation backslashes? In-Reply-To: Message from Matthias Klose of "Sat, 07 Aug 1999 16:33:02 +0200." <14252.17061.306678.337780@bolero> Date: Sat, 07 Aug 1999 09:45:26 -0700 From: Zack Weinberg Matthias Klose wrote: > How is cpp supposed to handle DOS newlines after line continuation > backslashes on a *nix platform? > > #define a(b) (b*\^M > b) > main() {printf("%d\n", a(5));} > > $ gcc foo.c > foo.c:2: parse error before `)' > foo.c:3: stray '\' in program > > ^M denotes the char with ASCII code 13. Without this char it works > like it should. > > $ gcc -E foo.c > # 1 "foo.c" > > b) > main() {printf("%d\n", ( 5 *\ );} Last time this came up, the consensus was that cpp should accept DOS newlines on all platforms. I implemented this in cpplib, but the normal preprocessor may not do it yet. zw From gcc-return-8905-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 17:38:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19793 invoked by alias); 7 Aug 1999 17:38:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19757 invoked from network); 7 Aug 1999 17:37:45 -0000 Received: from firewall.mindmaker.hu (194.152.134.8) by egcs.cygnus.com with SMTP; 7 Aug 1999 17:37:45 -0000 Received: (qmail 6738 invoked from network); 7 Aug 1999 19:36:56 -0000 Received: from garfield.inside (HELO mindmaker.hu) (192.168.1.125) by firewall.inside with SMTP; 7 Aug 1999 19:36:56 -0000 Message-ID: <37AC6EB8.77104066@mindmaker.hu> Date: Sat, 07 Aug 1999 19:36:56 +0200 From: Levente Farkas Reply-To: lfarkas@mindmaker.hu Organization: Mindmaker Ltd. X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: hu,en MIME-Version: 1.0 Newsgroups: comp.lang.c++.moderated To: Gary Granger CC: gcc@gcc.gnu.org, libstdc++@sourceware.cygnus.com, stl@sgi.com Subject: Re: mem_fun family (for_each, bind..) References: <199908062000.OAA01612@stout.atd.ucar.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Granger wrote: > > The draft standard I have lists the bind2nd declaration as follows: > > template > binder2nd bind2nd(const Operation&, const T&); > > It looks like the type 'double' you are passing cannot be used since it is > not constant. I replaced your reference with a pointer and it compiled and > ran with no problems: > > Across the ether fly the words of Levente Farkas: > ... > > void f(double& d) const { ++d; } > void f(double *d) const { ++(*d); } > ... > > std::bind2nd(std::mem_fun(&A::f), d)); > std::bind2nd(std::mem_fun(&A::f), &d)); > > > ... > > ms's compiler don't support it), but this simple example can't compile even > > on the latest egcs/gcc - 2.95! > > or am I wrong ? > > If you are not sure whether this "simple example" complies with the > standard, then perhaps it is not so simple, and you should instead let the > newsgroups answer the STL question *before* asking the bug question. you've got right, the problem is not just with the implementation. 1. there's a problem in the standard : bind2nd should have to be template binder2nd bind2nd(Operation, T); since it's a template and in this case if T == const double & than it don't need another const or &, what's more it can work in all case. 2. the implementations are bad, since it's not specialized to be a void Operation and since void in not real type (another bug in the standard you can't return with void) so you can't return with a void function in binder2nd's operator(). ps. in the sgi's stl the mem_fun family is specialized, but the bind2nd isn't (in the ms's stl you can't specialized -- Levente From gcc-return-8906-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 19:25:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27768 invoked by alias); 7 Aug 1999 19:25:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27751 invoked from network); 7 Aug 1999 19:25:18 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 7 Aug 1999 19:25:18 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id NAA29779; Sat, 7 Aug 1999 13:23:09 -0600 X-Mailer: exmh version 2.0.2 To: Toon Moene cc: gcc@gcc.gnu.org Subject: Re: Help! Is there a C++ doctor in the audience ? Reply-To: law@cygnus.com In-reply-to: Your message of Sat, 07 Aug 1999 16:25:31 +0200. <37AC41DB.54294F99@moene.indiv.nluug.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Aug 1999 13:23:09 -0600 Message-ID: <29776.934053789@upchuck.cygnus.com> From: Jeffrey A Law In message <37AC41DB.54294F99@moene.indiv.nluug.nl>you write: > > > I updated my local 2.95 repository at around 12 UTC today. > > Unfortunately, I get: One of the C++ changes installed on the branch is mis-behaving. I've already ruled out the libio changes, but I haven't yet identified the problem C++ change. One of the rather lame things about CVS is there is no way to say "update to the branch state at time XYZ". That makes nailing this kind of thing down on a branch hard -- enough that it might be worth tagging the release branch nightly with a date tag to make tracking this stuff down on a branch easier. jeff From gcc-return-8907-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 19:50:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29485 invoked by alias); 7 Aug 1999 19:50:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29470 invoked from network); 7 Aug 1999 19:50:12 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 7 Aug 1999 19:50:12 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id NAA29821; Sat, 7 Aug 1999 13:47:20 -0600 X-Mailer: exmh version 2.0.2 To: John Wehle cc: amylaar@cygnus.co.uk, gcc@gcc.gnu.org Subject: Re: Should dead stores which could trap be deleted? Reply-To: law@cygnus.com In-reply-to: Your message of Fri, 06 Aug 1999 21:32:36 EDT. <199908070132.VAA24676@jwlab.FEITH.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Aug 1999 13:47:20 -0600 Message-ID: <29818.934055240@upchuck.cygnus.com> From: Jeffrey A Law In message <199908070132.VAA24676@jwlab.FEITH.COM>you write: > Can a generalization be made that gcc is free to perform optimizations > which eliminates instructions that can trap so long that the resulting > code produces the right answer in any situation where the trap would > not have occurred? Or is each situation unique and a healthy dose > of common sense required? There are some generalities you can use. You can always delete unreachable code, no matter what that code might do, it can never be executed. During CSE types of optimizations you can delete a redundant instruction which might trap -- why? Because if it is redundant, then the earlier instruction would have trapped. Things get a little more iffy when deleting dead code. But I think we are OK deleting code which (according to ANSI/ISO) is undefined and the only possible side effect of that code is to trap. So removal of a divide whose result is unused is (IMHO) OK; similarly removal of an load instruction whose result is never used is OK. Things get even more iffy when considering motion of insns which might trap. Consider hoisting a loop invariant divide out of a loop. I think GCC's behavior in this case is rather inconsistent -- I *think* we disallow hoisting of division out of loops, but allow hoisting of memory references. Now consider something like lazy code motion which combines aspects of both cse and loop optimizations. It looks at loops as simply multiple paths to the same location -- so if there is an instruction which would compute the same value on the two paths, it is hoisted to an earlier location in the cfg (but nothing should be moved before the point at which we know we will eventually execute the loop for correctness purposes). What do we do with memory references, division, etc then??? jeff From gcc-return-8908-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 20:02:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30605 invoked by alias); 7 Aug 1999 20:02:41 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30590 invoked from network); 7 Aug 1999 20:02:38 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 7 Aug 1999 20:02:38 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id WAA01956; Sat, 7 Aug 1999 22:02:04 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id WAA00655; Sat, 7 Aug 1999 22:00:52 +0200 Date: Sat, 7 Aug 1999 22:00:52 +0200 Message-Id: <199908072000.WAA00655@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: drow@false.org CC: gcc@gcc.gnu.org In-reply-to: <19990807110722.A10855@them.org> (message from Daniel Jacobowitz on Sat, 7 Aug 1999 11:07:22 -0400) Subject: Re: [C++] Overloading a type name with a function References: <19990807110722.A10855@them.org> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > From what I can tell the definition of 'class A' is completely hidden > in C by 'bool B::A(int)'. Thus a syntax error in the declaration of > myA. Is this right, or should the compiler find the class A > declaration in the top level? This is right; the method shadows the class. To correct this, you can either write class C : public B { class A myA; }; or class C : public B { ::A myA; }; Regards, Martin From gcc-return-8909-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 20:06:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31959 invoked by alias); 7 Aug 1999 20:06:38 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31944 invoked from network); 7 Aug 1999 20:06:35 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 7 Aug 1999 20:06:35 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id OAA29901; Sat, 7 Aug 1999 14:04:33 -0600 X-Mailer: exmh version 2.0.2 To: jason@cygnus.com Cc: gcc@gcc.gnu.org Reply-To: law@cygnus.com Subject: bug in recent gcc-2.95 branch checkin Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Aug 1999 14:04:33 -0600 Message-ID: <29898.934056273@upchuck.cygnus.com> From: Jeffrey A Law This change is preventing libio from building on the gcc-2.95 branch: * pt.c (maybe_get_template_decl_from_type_decl): Make sure that we're looking at a class. jeff From gcc-return-8910-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 20:56:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2902 invoked by alias); 7 Aug 1999 20:56:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2886 invoked from network); 7 Aug 1999 20:56:46 -0000 Received: from garfield.dis.com (199.4.97.30) by egcs.cygnus.com with SMTP; 7 Aug 1999 20:56:46 -0000 Received: from garfield (199.4.97.30) by garfield.dis.com (EMWAC SMTPRS 0.81) with SMTP id ; Sat, 07 Aug 1999 13:56:45 -0700 Message-Id: <4.1.19990807132315.00ccc670@garfield.dis.com> X-Sender: mark@garfield.dis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 07 Aug 1999 13:56:43 -0700 To: gcc@gcc.gnu.org From: Mark Klein Subject: muldi3, divdi3 and remdi3 patterns Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I've got a puzzle that I've been poking at off and on for the past number of weeks, and I guess it's time to ask for help. In adding muldi3, divdi3 and remdi3 instruction patterns, I find that the compiler is choosing to do remsi3 as a widened X-Y*(X/Y) instead of simply using the remsi3 pattern. It starts down this path in expand_divmod when expand_mult_highpart recognizes it can use the muldi3 pattern. Any ideas? TIA, M. --- snip --- My source: #define HASH_TABLE_SIZE 31 extern int string_hash_fun(void); int internString() { return (string_hash_fun() % HASH_TABLE_SIZE); } --- the rtl --- ;; Function internString (note 2 0 3 "" NOTE_INSN_DELETED) (note 3 2 4 "" NOTE_INSN_FUNCTION_BEG) (note 4 3 6 "" NOTE_INSN_DELETED) (note 6 4 8 "" NOTE_INSN_DELETED) (call_insn 8 6 10 (parallel[ (set (reg:SI 28 %r28) (call (mem:SI (symbol_ref/v:SI ("@string_hash_fun")) 0) (const_int 16 [0x10]))) (clobber (reg:SI 2 %r2)) (use (const_int 0 [0x0])) ] ) -1 (nil) (nil) (nil)) (insn 10 8 14 (set (reg:SI 95) (reg:SI 28 %r28)) -1 (nil) (nil)) (insn 14 10 17 (set (reg:SI 99) (ashiftrt:SI (reg:SI 95) (const_int 31 [0x1f]))) -1 (nil) (nil)) (insn 17 14 12 (clobber (reg:DI 98)) -1 (nil) (insn_list:REG_LIBCALL 19 (nil))) (insn 12 17 16 (set (subreg:SI (reg:DI 98) 1) (reg:SI 95)) -1 (nil) (expr_list:REG_NO_CONFLICT (reg:SI 95) (nil))) (insn 16 12 19 (set (subreg:SI (reg:DI 98) 0) (reg:SI 99)) -1 (nil) (expr_list:REG_NO_CONFLICT (reg:SI 95) (nil))) (insn 19 16 20 (set (reg:DI 98) (reg:DI 98)) -1 (nil) (insn_list:REG_RETVAL 17 (expr_list:REG_EQUAL (sign_extend:DI (reg:SI 95)) (nil)))) (insn 20 19 21 (set (reg:DI 101) (high:DI (const_int -2078209981 [0x84210843]))) -1 (nil) (nil)) (insn 21 20 22 (set (reg:DI 100) (lo_sum:DI (reg:DI 101) (const_int -2078209981 [0x84210843]))) -1 (nil) (nil)) (insn 22 21 23 (set (reg:DI 25 %r25) (reg:DI 98)) -1 (nil) (nil)) (insn 23 22 24 (set (reg:DI 23 %r23) (reg:DI 100)) -1 (nil) (nil)) (insn 24 23 25 (parallel[ (set (reg:DI 28 %r28) (mult:DI (reg:DI 25 %r25) (reg:DI 23 %r23))) (clobber (reg:SI 102)) (clobber (reg:DI 25 %r25)) (clobber (reg:DI 23 %r23)) (clobber (reg:SI 31 %r31)) ] ) -1 (nil) (nil)) (insn 25 24 26 (set (reg:DI 97) (reg:DI 28 %r28)) -1 (nil) (expr_list:REG_EQUAL (mult:DI (reg:DI 98) (reg:DI 100)) (nil))) (insn 26 25 28 (set (reg:SI 103) (plus:SI (reg:SI 95) (subreg:SI (reg:DI 97) 0))) -1 (nil) (nil)) (insn 28 26 30 (set (reg:SI 104) (ashiftrt:SI (reg:SI 103) (const_int 4 [0x4]))) -1 (nil) (nil)) (insn 30 28 31 (set (reg:SI 105) (ashiftrt:SI (reg:SI 95) (const_int 31 [0x1f]))) -1 (nil) (nil)) (insn 31 30 33 (set (reg:SI 94) (minus:SI (reg:SI 104) (reg:SI 105))) -1 (nil) (expr_list:REG_EQUAL (div:SI (reg:SI 95) (const_int 31 [0x1f])) (nil))) (insn 33 31 35 (set (reg:SI 106) (reg:SI 94)) -1 (nil) (nil)) (insn 35 33 36 (set (reg:SI 107) (ashift:SI (reg:SI 106) (const_int 5 [0x5]))) -1 (nil) (expr_list:REG_EQUAL (mult:SI (reg:SI 94) (const_int 32 [0x20])) (nil))) (insn 36 35 37 (set (reg:SI 107) (minus:SI (reg:SI 107) (reg:SI 94))) -1 (nil) (expr_list:REG_EQUAL (mult:SI (reg:SI 94) (const_int 31 [0x1f])) (nil))) (insn 37 36 39 (set (reg:SI 94) (minus:SI (reg:SI 95) (reg:SI 107))) -1 (nil) (nil)) (insn 39 37 40 (set (reg/i:SI 28 %r28) (reg:SI 94)) -1 (nil) (nil)) (insn 40 39 41 (use (reg/i:SI 28 %r28)) -1 (nil) (nil)) (jump_insn 41 40 42 (set (pc) (label_ref 46)) -1 (nil) (nil)) (barrier 42 41 44) (note 44 42 46 "" NOTE_INSN_FUNCTION_END) (code_label 46 44 0 2 "" [num uses: 0]) --- snip --- -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available From gcc-return-8911-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 21:51:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7149 invoked by alias); 7 Aug 1999 21:50:58 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7134 invoked from network); 7 Aug 1999 21:50:55 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 7 Aug 1999 21:50:55 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA29103; Sat, 7 Aug 1999 14:50:55 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id OAA13057; Sat, 7 Aug 1999 14:50:54 -0700 To: law@cygnus.com Cc: gcc@gcc.gnu.org Subject: Re: bug in recent gcc-2.95 branch checkin References: <29898.934056273@upchuck.cygnus.com> From: Jason Merrill Date: 07 Aug 1999 14:50:54 -0700 In-Reply-To: Jeffrey A Law's message of "Sat, 07 Aug 1999 14:04:33 -0600" Message-ID: Lines: 3 X-Mailer: Gnus v5.6.45/Emacs 20.3 Reverted. Jason From gcc-return-8912-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 22:17:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8855 invoked by alias); 7 Aug 1999 22:17:32 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8840 invoked from network); 7 Aug 1999 22:17:29 -0000 Received: from latte.2xtreme.net (209.63.222.34) by egcs.cygnus.com with SMTP; 7 Aug 1999 22:17:29 -0000 Received: (qmail 18071 invoked from network); 7 Aug 1999 22:21:26 -0000 Received: from p204.oak3.2xtreme.net (HELO 2xtreme.net) (209.63.216.204) by latte.2xtreme.net with SMTP; 7 Aug 1999 22:21:26 -0000 Message-ID: <37ACB06E.88C2014B@2xtreme.net> Date: Sat, 07 Aug 1999 15:17:18 -0700 From: Dara Hazeghi X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Toon Moene CC: gcc@gcc.gnu.org Subject: Re: GCC 2.95 and floating point precision References: <37AB6A5C.55EC7936@cup.hp.com> <37AC2628.C9F3174B@moene.indiv.nluug.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Toon Moene wrote: > Dara Hazeghi wrote: > > > I recently downloaded and built your gcc2.95 release (Never trusted RPMS > > anyway) on an i686-pc-linux-gnu. I have a program which demands the full > > 80bit precision in the Pentium FPU. It's written entirely in C and built > > and ran fine with gcc2.91.66 (aka egcs 1.1.2). Now however it won't run > > due to a lack of floating point precision. I am almost certain of this > > due to the fact that with a similar version of the program only > > requiring 64bit precision, the calculations work flawleesly (albeit > > slower). This problem only happens with -O2 or -O3 optimization levels. > > With -O1 or -O0 I can enable pretty much any other optimizations > > supported by x86 (including -ffast-math) and the code builds and runs > > fine. Is there any changes between gcc2.91.66 and gcc2.95 that restricts > > this use of the Pentium FPU? The program is doing mathematical > > computation, so I really need the extra 16 bits! Thank for any insight > > on the topic. > > Well, I'm not a C guru, but I get from the above that you have two > versions of your program, one with all floating point variables and > arrays declared `long double' and another with all of them declared > `double' - is that correct ? The `double' variant seems to work OK when > compiled with gcc-2.95 and the `long double' variant does not ? That's about how it works out yes. > > > I do not think any change in gcc-2.95 w.r.t. egcs-1.1.2 was _meant_ to > introduce a change in floating point arithmetic, so the behaviour you're > seeing might well point to a bug. > > Could you supply: > > 1. The failing source in question (with input and _expected_ output) Certainly. It's available at http://www.2xtreme.net/hazeghi/pi/pic586.tar.gz . Type "make" and go "./pic586 128k" and it calculates 128k digits of Pi. Type "make broken" (which just compiles with -O2 instead of -O1) and go "./pic586 128k" and you'll get an error message. The built in self check for the sqrt2 function are failing. > > 2. The options given to gcc when compiling it that lead to the failing > executable -O2 or -O3 > > 3. [Optional] the extra option in addition to -O1 which makes the > executable fail ? There are _no_ options that cause a failure with -O1 or -O0. Believe me I have tried! > > > > On a different topic, is there any way of getting the clobber register > > asm code that is so deprecated to build on gcc2.95 (maybe > > --fallow-clobber-registers or something). Yes I know you're supposed to > > rewrite the code, but what if you can't (I don't know asm). Thanks > > again. > > The only way to compile that code is to use egcs-1.1.2 - At Your Own > Risk [it doesn't have a well-defined meaning]. The author is working on fixing it, but this really isn't a great way to promote gcc2.95. I know all you people put an incredible amount of work into gcc2.95 and for most things it excels, but unless I'm much mistaken it could have been left in with a warning that it might generate bad code. -fno-strict-aliasing was for the purpose of backward compatibility and it is essential. Something of the same style for clobber would have really simplified issues. Thanks for your time Dara Hazeghi On another aside, are there any changes with the configure scripts in gcc. When I do ./configure --target=alpha-linux I get the usage for the configure script. How is one supposed to configure to build a cross compiler in this day and age. Thanks again. From gcc-return-8913-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 23:21:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14478 invoked by alias); 7 Aug 1999 23:21:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14453 invoked from network); 7 Aug 1999 23:21:13 -0000 Received: from 209-249-66-150.snj0.flashcom.net (HELO ocean.lucon.org) (postfix@209.249.66.150) by egcs.cygnus.com with SMTP; 7 Aug 1999 23:21:13 -0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 8522657B9; Sat, 7 Aug 1999 16:21:12 -0700 (PDT) Subject: Re: binutils 2.9.5.0.5 still trigger the last bug - static libstdc++ required To: wwc@rentec.com (Wolfgang Wander) Date: Sat, 7 Aug 1999 16:21:12 -0700 (PDT) Cc: jj@sunsite.ms.mff.cuni.cz, ian@zembu.com (Ian Lance Taylor), binutils@sourceware.cygnus.com, egcs@egcs.cygnus.com In-Reply-To: <14252.25683.4588.53797@gargle.gargle.HOWL> from "Wolfgang Wander" at Aug 07, 1999 12:52:35 PM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990807232112.8522657B9@ocean.lucon.org> From: hjl@lucon.org (H.J. Lu) > > Jakub Jelinek writes: > > > after Ian checked in your patch yesterday morning I still had this > > > problem - with binutils-2.9.5.0.5 I can no longer reproduce it though. > > > > > > Should I try it again with an updated cvs version? > > > > Strange. 2.9.5.0.5 seems to have my patch and from that time on I'm not > > aware of any sparc related changes. > > If you can, could you check latest cvs version? If the problem remains, > > could you please send me the binary of libNope.so from old binutils, cvs > > mainline and perhaps 2.9.5.0.5? > > I could arrange to get access to one Solaris box, but it would take a few > > days, so it would be easier for me to inspect things on a sparc64-linux box. > > Jakub, Ian, H.J, > > here we go - the bug is still present in both binutils-2.9.5.0.5 > and the current cvs tree. > > You can however only trigger it by linking against a static > libstd++ (the only way I could convince gcc to avoid the .so was > to chmod 0 libstdc++.so*). The bug does not show up when you link > against a dynamic libstd++. > > So after you run chmod 0 on your libstd++.so* (or build gcc without > --enable-shared) you should run the script below to see the core dump > and the behaviour described below. The bug has been in binutils for a while. Ian, Jakub, with "make check" in ld, I got FAIL: shared (non PIC) FAIL: shared (non PIC, load offset) FAIL: shared (PIC main, non PIC so) I believe it is related to this bug. When # g++ -G -o libNope.so libNope.C is used to generate a DSO, -lstdc++ is passed to ld. If there is no libstd++.so, libstdc++.a will be used. However, gnu ld doesn't do the right thing on Solaris/Sparc. Before gnu ld is fixed, the workarounds are: 1. Use the native ld. Or 2. Use # gcc -G -o libNope.so libNope.C instead of # g++ -G -o libNope.so libNope.C It is better than putting non PIC code in a shared library. Or 3. Fix g++ such that passing -lstdc++ to ld for -G/-shared when building shared library only if --enable-shared is used. It doesn't make any senses to include libstdc++.a for a DSO. My preferences are 3, 2 and 1. I may work on a patch for 3 if everyone thinks it is a good idea. Thanks. H.J. ---- > > Hope this helps. > > > You guys are great - but you know that ;-) > > Wolfgang > > To: Ian Lance Taylor > Cc: hjl@lucon.org > Subject: Re: binutils 2.9.1.0.25 - solaris / gcc2.95 > Date: Fri, 6 Aug 1999 13:19:57 -0400 (EDT) > > Ian and H.J., > > here is another problem I ran into - it seems not to be gcc related > as static linking does not trigger the bug. > > The following example code > > ---------------------------------------------------------------------- > #!/bin/sh > > echo ' > void bugme(void); > int main() { > bugme(); > }' > test.C > > echo ' > #include > #include > #include > void bugme(void) { > string a_string("a string of some size"); > ostrstream ostr; > ostr << a_string << '"'"'\0'"'"'; > cout << ostr.str() << endl; > ostr.freeze(false); > } > ' > libNope.C > > > CC="g++-2.95-gnu -fPIC -g" > $CC -G -o libNope.so libNope.C > $CC -c -o libNope.o libNope.C > ar rv libNope.a libNope.o > $CC -g test.C -o bug -L. -lNope -Wl,-R`pwd` > $CC -g -static test.C -o nobug -L. -lNope > > echo '===============' > echo 'output of bug' > ./bug > echo 'output of nobug' > ./nobug > > > ---------------------------------------------------------------------- > produces (on solaris 2.6 with the binutils checked out this morning): > > ----------------- > output of bug > Segmentation Fault - core dumped > output of nobug > a string of some size > ------------------ > > so the dynamicly linked executable crashes whereas the static one is > fine. > > It crashes in _IO_str_overflow where > > 143 new_buf > 144 = (char *) (*((_IO_strfile *) > fp)->_s._allocate_buffer) (new_size); > > > > ((_IO_strfile *) fp)->_s is a *static* member of ostrstream and its > data member point to point to undefined addresses - looks like another > static constructor problem (if I may guess so ;-) > > > (gdb) print ((_IO_strfile *) fp)->_s > $3 = {_allocate_buffer = 0xef747848 , _free_buffer > = 0xef747 > 85c } > > > If I link the binary dynamicly I get (at the same breakpoint) > > > (gdb) print ((_IO_strfile *) fp)->_s > $1 = {_allocate_buffer = 0x178f8 , > _free_buffer = 0 > x1790c } > > > egcs-1.1.2 (binutils 2.9.1) works for both the dynamic and the static > case. > > > Wolfgang > > From gcc-return-8914-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 07 23:43:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16037 invoked by alias); 7 Aug 1999 23:43:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16022 invoked from network); 7 Aug 1999 23:43:46 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 7 Aug 1999 23:43:46 -0000 Received: from cs.ucla.edu (ts52-41.wla.ts.ucla.edu [164.67.25.70]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id QAA29193; Sat, 7 Aug 1999 16:43:44 -0700 (PDT) Message-ID: <37ACC565.72A14E9A@cs.ucla.edu> Date: Sat, 07 Aug 1999 16:46:45 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: a barely useful option? References: <37ACBBA3.DF51EF35@cs.ucla.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit g++ -Weffc++ test.cxx gives a ton of warnings when compiling #include int main() {} which seemingly makes -Weffc++ unuseful (I also tried ). Given the multitude of g++ options that are documented not to be very useful, I am not sure whether it's the option that can be removed or the stdlibc++ fixed according to Scott Meyers' Effective C++ books. Not a heartbreaker, of course, just wanted to let you know. Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8915-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 08 01:12:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21094 invoked by alias); 8 Aug 1999 01:12:20 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21009 invoked from network); 8 Aug 1999 01:12:15 -0000 Received: from comton.airs.com (199.103.241.106) by egcs.cygnus.com with SMTP; 8 Aug 1999 01:12:15 -0000 Received: (qmail 27715 invoked by uid 4); 8 Aug 1999 01:12:10 -0000 Received: (qmail 32224 invoked by uid 269); 8 Aug 1999 01:11:53 -0000 Message-ID: <19990808011153.32223.qmail@daffy.airs.com> Date: 7 Aug 1999 21:11:53 -0400 From: Ian Lance Taylor To: hjl@lucon.org CC: wwc@rentec.com, jj@sunsite.ms.mff.cuni.cz, binutils@sourceware.cygnus.com, egcs@egcs.cygnus.com In-reply-to: <19990807232112.8522657B9@ocean.lucon.org> (hjl@lucon.org) Subject: Re: binutils 2.9.5.0.5 still trigger the last bug - static libstdc++ required References: <19990807232112.8522657B9@ocean.lucon.org> Date: Sat, 7 Aug 1999 16:21:12 -0700 (PDT) From: hjl@lucon.org (H.J. Lu) I don't have an easy way to test problems on Solaris, so I'm waiting for somebody to find the problem or produce a test case I can look at (i.e., one which does not require building gcc or libstdc++ and which does not require the Solaris startup files or libraries). The bug has been in binutils for a while. Ian, Jakub, with "make check" in ld, I got FAIL: shared (non PIC) FAIL: shared (non PIC, load offset) FAIL: shared (PIC main, non PIC so) This suggests a bug in handling relocations when generating shared libraries. I believe it is related to this bug. When # g++ -G -o libNope.so libNope.C is used to generate a DSO, -lstdc++ is passed to ld. If there is no libstd++.so, libstdc++.a will be used. However, gnu ld doesn't do the right thing on Solaris/Sparc. Before gnu ld is fixed, the workarounds are: 1. Use the native ld. Or 2. Use # gcc -G -o libNope.so libNope.C instead of # g++ -G -o libNope.so libNope.C It is better than putting non PIC code in a shared library. Or 3. Fix g++ such that passing -lstdc++ to ld for -G/-shared when building shared library only if --enable-shared is used. It doesn't make any senses to include libstdc++.a for a DSO. My preferences are 3, 2 and 1. I may work on a patch for 3 if everyone thinks it is a good idea. To me it makes perfect sense to include libstdc++.a in a shared object. Anyhow, it seems silly to patch g++ merely because there is a bug in ld. We should just fix the bug in ld. A bug like this can't be hard to fix, especially since the GNU linker used to pass those tests on Solaris. Ian From gcc-return-8916-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 08 02:37:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27433 invoked by alias); 8 Aug 1999 02:37:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27413 invoked from network); 8 Aug 1999 02:37:29 -0000 Received: from dragonfly.wolfram.com (root@140.177.10.12) by egcs.cygnus.com with SMTP; 8 Aug 1999 02:37:29 -0000 Received: from m.wolfram.com (root@m.wolfram.com [140.177.201.20]) by dragonfly.wolfram.com (8.8.8/8.8.8) with ESMTP id VAA14414; Sat, 7 Aug 1999 21:37:16 -0500 (CDT) Received: from localhost (johnnyb@localhost) by m.wolfram.com (8.9.3/8.9.2) with ESMTP id VAA26538; Sat, 7 Aug 1999 21:34:27 -0500 Date: Sat, 7 Aug 1999 21:34:27 -0500 (CDT) From: Jonathan Bartlett To: gcc@gcc.gnu.org, kenner@vlsi1.ultra.nyu.edu Subject: Toy language Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In case anyone's interested, I've updated the toy language(a short, simple language meant to give an example of a GCC front-end) to work with GCC 2.95. It is available at http://members.wri.com/johnnyb/compilers/ for anyone who's interested. There are also links to various materials that I have found on the internet related to GCC front-end development. I don't know much about front-end development personally (although I'm trying to learn), but I can try to answer anyone's questions about the language if they're interested in taking a look at it. Jonathan Bartlett johnnyb@wolfram.com From gcc-return-8917-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 08 12:45:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23481 invoked by alias); 8 Aug 1999 12:45:27 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23466 invoked from network); 8 Aug 1999 12:45:24 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 8 Aug 1999 12:45:24 -0000 Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id IAA22380; Sun, 8 Aug 1999 08:45:18 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com by world.std.com (TheWorld/Spike-2.0) id AA13929; Sun, 8 Aug 1999 08:44:53 -0400 Received: (qmail 9083 invoked by uid 500); 8 Aug 1999 12:44:29 -0000 Date: 8 Aug 1999 12:44:29 -0000 Message-Id: <19990808124429.9082.qmail@deer> To: hazeghi@2xtreme.net Cc: toon@moene.indiv.nluug.nl, gcc@gcc.gnu.org Cc: craig@jcb-sc.com In-Reply-To: <37ACB06E.88C2014B@2xtreme.net> (message from Dara Hazeghi on Sat, 07 Aug 1999 15:17:18 -0700) Subject: Re: GCC 2.95 and floating point precision References: <37AB6A5C.55EC7936@cup.hp.com> <37AC2628.C9F3174B@moene.indiv.nluug.nl> <37ACB06E.88C2014B@2xtreme.net> >The author is working on fixing it, but this really isn't a great way to >promote gcc2.95. I know all you people put an incredible amount of work into >gcc2.95 and for most things it excels, but unless I'm much mistaken it could >have been left in with a warning that it might generate bad code. >-fno-strict-aliasing was for the purpose of backward compatibility and it is >essential. Something of the same style for clobber would have really >simplified issues. Excuse me, but...*all* compilers might generate bad code. If you know of any counterexamples, please use those, and, let us know. Also, I have not been watching this thread *real* closely, but, my impression is, you have not yet identified any bug in gcc pertaining to your code. Therefore, it's quite likely the bug is in your code, and, as is so often the case, you're complaining about gcc exposing it by optimizing it sufficiently to expose the bug. If Toon wants to try to debug your code for you, great, but, unless I've missed where you've already done this, please read the FAQ item on how to report bugs and track this bug down. Then, you'll probably be able to fix your code -- or, if you happen to find a compiler bug, you'll have a more useful bug report to submit. "My program doesn't behave as I expect with your new compiler, but it behaved okay with the old" (or variations thereof) are almost always statements made by people who have buggy programs, but haven't figured that out yet. (My guess is that you're hitting the truncating-spills problem.) tq vm, (burley) From gcc-return-8918-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 08 14:17:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31155 invoked by alias); 8 Aug 1999 14:17:57 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31140 invoked from network); 8 Aug 1999 14:17:53 -0000 Received: from mail.omnilink.net (194.64.25.6) by egcs.cygnus.com with SMTP; 8 Aug 1999 14:17:53 -0000 Received: from bettina-desk ([194.195.180.200]) by mail.omnilink.net (8.9.3/8.9.3) with SMTP id QAA04722; Sun, 8 Aug 1999 16:17:16 +0200 (MET DST) Message-Id: <3.0.32.19990808161644.0093e050@mail.omnilink.net> X-Sender: pop03199@mail.omnilink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 08 Aug 1999 16:16:47 +0200 To: Igor Markov , gcc@gcc.gnu.org From: Dietmar Kuehl Subject: Re: a barely useful option? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi, At 16:46 07.08.99 -0700, Igor Markov wrote: > > g++ -Weffc++ test.cxx > gives a ton of warnings when compiling > >#include >int main() {} > > which seemingly makes -Weffc++ unuseful (I also tried ). With a reasonably implemented standard library this options is quite useful! My implementation of the IOStream library currently issues only warnings if deprecated library features are used even with maximum warning level (-W -Wall -Weffc++ -ansi -pedantic). There are a bunch of iterator classes which, when implemented according to the standard, issue a warning for operator++(int) (eg. ostreambuf_iterator) but I thought about submitting a patch to avoid this warning for these classes. If you want to have a look at this implementation, you can get a working version from (currenty I'm preparing a complete release which will involve a name change to avoid confusing this library with libstdc++). > Given the multitude of g++ options that are documented not to be very > useful, I am not sure whether it's the option that can be removed or > the stdlibc++ fixed according to Scott Meyers' Effective C++ books. I think the library should be fixed. In any case, even if the library is not fixed, the warning should not be removed: There will be a library which will not cause any warnings and especially new users of C++ will benefit from this warning. Regards, Dietmar From gcc-return-8919-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 08 14:25:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32765 invoked by alias); 8 Aug 1999 14:25:00 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32749 invoked from network); 8 Aug 1999 14:24:58 -0000 Received: from imo16.mx.aol.com (198.81.17.6) by egcs.cygnus.com with SMTP; 8 Aug 1999 14:24:58 -0000 Received: from N8TM@aol.com by imo16.mx.aol.com (mail_out_v22.4.) id 6FEAa00252 (4467); Sun, 8 Aug 1999 10:22:39 -0400 (EDT) From: N8TM@aol.com Message-ID: <22e1c662.24deecaf@aol.com> Date: Sun, 8 Aug 1999 10:22:39 EDT Subject: Re: GCC 2.95 and floating point precision To: craig@jcb-sc.com, hazeghi@2xtreme.net CC: toon@moene.indiv.nluug.nl, gcc@gcc.gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows sub 3 In a message dated 8/8/99 4:47:10 AM PST, craig@jcb-sc.com writes: > the bug is in your code, and, as is so often > the case, you're complaining about gcc exposing it by optimizing it > sufficiently to expose the bug. I've been seeing what may be a similar situation: Elefunt (Plauger's C version) is reporting a loss of 9 bits (relative to expected 53) for exp() and 6 bits for pow() when compiled with optimization in gcc-2.95 on cygwin. There is no such problem with expl() and powl() (relative to expected 64 bit precision), nor is there a problem without optimization. The problem goes away on my linux/libc6 installation although I expect it could be replicated with careful disabling of the MATH_INLINE feature. Speaking of libc6, several of the long double math functions are inadequate (even pow() shows some failures), and even more unpredictable results may be provoked by the in-lining feature in C. Maybe we don't want to open that can of worms in g77 (except for pow(), which is biting us already)! Tim tprince@computer.org From gcc-return-8920-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 08 14:25:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 445 invoked by alias); 8 Aug 1999 14:25:27 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 411 invoked from network); 8 Aug 1999 14:25:26 -0000 Received: from ne.mediaone.net (HELO chmls05.mediaone.net) (24.128.1.70) by egcs.cygnus.com with SMTP; 8 Aug 1999 14:25:26 -0000 Received: from moshier.ne.mediaone.net (moshier.ne.mediaone.net [24.218.56.120]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id KAA23727; Sun, 8 Aug 1999 10:22:10 -0400 (EDT) Date: Sun, 8 Aug 1999 10:22:11 -0400 (EDT) From: Stephen L Moshier X-Sender: moshier@moshier.ne.mediaone.net Reply-To: moshier@mediaone.net To: Toon Moene , Dara Hazeghi cc: gcc@gcc.gnu.org Subject: Re: GCC 2.95 and floating point precision Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII GCC-2.95 is more sensitive than any previous GCC version has been to the floating point pointer aliasing feature-bug of ANSI C. The program you referenced contains code that is not valid ANSI C, such as the following: long double ChopVar; *Lo = *((unsigned long int *) &ChopVar); *Hi = (*(((unsigned long int *) &ChopVar) + 1)) & ~2147483648U; You may not do this any more. It is verboten. You are supposed to use a union containing the float and the int together. From gcc-return-8921-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 08 15:29:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7095 invoked by alias); 8 Aug 1999 15:29:19 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7078 invoked from network); 8 Aug 1999 15:29:16 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 8 Aug 1999 15:29:16 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id RAA00677; Sun, 8 Aug 1999 17:28:25 +0200 Message-ID: <37ADA219.FF2F9416@moene.indiv.nluug.nl> Date: Sun, 08 Aug 1999 17:28:25 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: Dara Hazeghi CC: gcc@gcc.gnu.org Subject: Re: GCC 2.95 and floating point precision References: <37AB6A5C.55EC7936@cup.hp.com> <37AC2628.C9F3174B@moene.indiv.nluug.nl> <37ACB06E.88C2014B@2xtreme.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dara Hazeghi wrote: > The author is working on fixing it, but this really isn't a great way to > promote gcc2.95. I know all you people put an incredible amount of work into > gcc2.95 and for most things it excels, but unless I'm much mistaken it could > have been left in with a warning that it might generate bad code. > -fno-strict-aliasing was for the purpose of backward compatibility and it is > essential. Something of the same style for clobber would have really > simplified issues. See the explanation at: http://egcs.cygnus.com/faq.html#asmclobber It's not possible to have a `backwards compatibility switch' here, because the asm's are really wrong. The FAQ entry even explains that the confusion was partly due to the fact that the documentation on asms was ambiguous. These constructs simply do not have a well-defined meaning (as I wrote before) and therefore, strictly speaking, cannot be compiled "correctly". I'm sorry, I do not know enough of this side of gcc to explain this better. > On another aside, are there any changes with the configure scripts in gcc. > When I do ./configure --target=alpha-linux I get the usage for the configure > script. How is one supposed to configure to build a cross compiler in this > day and age. See: http://egcs.cygnus.com/faq.html#cross Hope this helps, -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-8922-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 08 16:06:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12666 invoked by alias); 8 Aug 1999 16:06:21 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12647 invoked from network); 8 Aug 1999 16:06:12 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 8 Aug 1999 16:06:12 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id SAA01117; Sun, 8 Aug 1999 18:05:18 +0200 Message-ID: <37ADAABE.9E9B7186@moene.indiv.nluug.nl> Date: Sun, 08 Aug 1999 18:05:18 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: moshier@mediaone.net CC: Dara Hazeghi , gcc@gcc.gnu.org Subject: Re: GCC 2.95 and floating point precision References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen L Moshier wrote: > > GCC-2.95 is more sensitive than any previous GCC version has been > to the floating point pointer aliasing feature-bug of ANSI C. :-) > The program you referenced contains code that is not valid ANSI C, > such as the following: > > long double ChopVar; > *Lo = *((unsigned long int *) &ChopVar); > *Hi = (*(((unsigned long int *) &ChopVar) + 1)) & ~2147483648U; > > You may not do this any more. It is verboten. You are supposed to use > a union containing the float and the int together. Phew - it's questionable whether I would ever have found that. Thanks, Stephen ... Using either -O1 or -O2 -fno-strict-aliasing delivers the same result. Far be it from me to proclaim that it's the _correct_ result - I only know the 20 leading digits of pi (and that's including the `3'). HTH, -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-8923-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 08 20:55:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11547 invoked by alias); 8 Aug 1999 20:55:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11513 invoked from network); 8 Aug 1999 20:55:35 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 8 Aug 1999 20:55:35 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id WAA21026; Sun, 8 Aug 1999 22:54:51 +0200 Message-ID: <37ADEE9B.2F09C701@moene.indiv.nluug.nl> Date: Sun, 08 Aug 1999 22:54:51 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: craig@jcb-sc.com CC: gcc@gcc.gnu.org Subject: Re: GCC 2.95 and floating point precision References: <37AB6A5C.55EC7936@cup.hp.com> <37AC2628.C9F3174B@moene.indiv.nluug.nl> <37ACB06E.88C2014B@2xtreme.net> <19990808124429.9082.qmail@deer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit craig@jcb-sc.com wrote: > (My guess is that you're hitting the truncating-spills problem.) Yep - that was my guess too - therefore I was willing to go to great lengths debugging this ... I wanted to have a real example where this hurt someone to convince myself of the extent of the problem. Unfortunately, the real cause was much more mundane ;-) Besides, I was beaten by Stephen Moshier while still trying to wrap my head around the code in question (i.e. the *.c files, while the problem was in crt.h ...) I think I'll stick to g77 bug reports from now on :-( -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-8924-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 08 22:36:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22936 invoked by alias); 8 Aug 1999 22:36:53 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22916 invoked from network); 8 Aug 1999 22:36:50 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 8 Aug 1999 22:36:50 -0000 Received: from cs.ucla.edu (ts22-8.wla.ts.ucla.edu [164.67.20.181]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id PAA17049; Sun, 8 Aug 1999 15:36:47 -0700 (PDT) Message-ID: <37AE0733.AF5DC818@cs.ucla.edu> Date: Sun, 08 Aug 1999 15:39:47 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: a few quick questions (-fPIC vs -fpic) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, 1. Is it true that -fpic and -fPIC on Linux/i*86 are no different? (The manual seems to imply this) 2. They are difft on Solaris. Is there a good upper bound on losses from -fPIC measured as (a) size of the libs and executables, (b) compile time, (c) link time, (d) load time, (e) run time (I guess, (d) is small anyways, but all others can be fairly big) Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-8925-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 03:26:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20994 invoked by alias); 9 Aug 1999 03:26:28 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20948 invoked from network); 9 Aug 1999 03:26:21 -0000 Received: from mescaline.gnu.org (158.121.106.21) by egcs.cygnus.com with SMTP; 9 Aug 1999 03:26:21 -0000 Received: from thor.xraylith.wisc.edu (thor.xraylith.wisc.edu [198.150.6.11]) by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id WAA03266 for ; Sun, 8 Aug 1999 22:54:40 -0400 Received: from mercury.xraylith.wisc.edu (mercury.xraylith.wisc.edu [128.104.182.221]) by thor.xraylith.wisc.edu (8.9.1a/8.9.1) with ESMTP id VAA08458 for ; Sun, 8 Aug 1999 21:54:32 -0500 Received: from mercury.xraylith.wisc.edu (localhost [127.0.0.1]) by mercury.xraylith.wisc.edu (8.8.7/8.8.7) with ESMTP id VAA28193 for ; Sun, 8 Aug 1999 21:54:35 -0500 Message-Id: <199908090254.VAA28193@mercury.xraylith.wisc.edu> To: gcc@gcc.gnu.org Subject: RFC: line endings and specs parser Date: Sun, 08 Aug 1999 21:54:35 -0500 From: Mumit Khan Now that GCC is slowly but surely moving towards dealing with the various types of EOLs (thanks Zack!), what do folks think about fixing specs parser to do the same? The problem is that the gcc.c:read_specs() doesn't use stdio to read the file, so all the usual conversions don't happen. My first attempt was to do graft it on top of existing code, but the code became extremely hard to read. My second attempt worked much better, but at the expense of a bit of memory and some processing overhead. After reading the specs using read(), I allocate a 2nd buffer, copy the 1st onto 2nd using the following simple logic: for each character in input buffer, - if '\r', transform to '\n'. - if next character is '\n', advance input pointer (ie, just skip). - copy to output buffer This should handle EOL styles of \n, \r\n and \r. Comments? Is this worth it? Regards, Mumit From gcc-return-8926-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 04:26:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29140 invoked by alias); 9 Aug 1999 04:26:30 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-owner@gcc.gnu.org List-Help: List-Archive: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29125 invoked from network); 9 Aug 1999 04:26:28 -0000 Received: from adsl-216-102-199-253.dsl.snfc21.pacbell.net (HELO magnus.bothner.com) (root@216.102.199.253) by egcs.cygnus.com with SMTP; 9 Aug 1999 04:26:28 -0000 Received: by bothner.com via sendmail from stdin id (Debian Smail3.2.0.102) for gcc@gcc.gnu.org; Sun, 8 Aug 1999 21:32:22 -0700 (PDT) To: Mumit Khan Cc: gcc@gcc.gnu.org Subject: Re: RFC: line endings and specs parser References: <199908090254.VAA28193@mercury.xraylith.wisc.edu> From: Per Bothner Date: 08 Aug 1999 21:32:22 -0700 In-Reply-To: Mumit Khan's message of "Sun, 08 Aug 1999 21:54:35 -0500" Message-ID: Lines: 16 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta14) (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > My second attempt worked much better, but at the expense of a bit of > memory and some processing overhead. After reading the specs using > read(), I allocate a 2nd buffer, copy the 1st onto 2nd using the > following simple logic: You could always do the transformation in place - just use two pointers into the same buffer. You do an initial scan looking for the first '\r': If none is found, you're done; otherwise, start copying (in place) from there. (I tend to prefer to do the processing "as you read" - i.e. whoever is parsing the specs file should do handle any of the conventions. However, it can be difficult to do that cleanly, and often it is faster to do a pre-pass.) -- --Per Bothner bothner@pacbell.net per@bothner.com http://home.pacbell.net/bothner/ From gcc-return-8927-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 04:55:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1593 invoked by alias); 9 Aug 1999 04:55:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1570 invoked from network); 9 Aug 1999 04:55:39 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 9 Aug 1999 04:55:39 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id WAA00336; Sun, 8 Aug 1999 22:53:25 -0600 X-Mailer: exmh version 2.0.2 To: Mumit Khan cc: gcc@gcc.gnu.org Subject: Re: RFC: line endings and specs parser Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 08 Aug 1999 21:54:35 CDT. <199908090254.VAA28193@mercury.xraylith.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Aug 1999 22:53:25 -0600 Message-ID: <333.934174405@upchuck.cygnus.com> From: Jeffrey A Law In message <199908090254.VAA28193@mercury.xraylith.wisc.edu>you write: > My second attempt worked much better, but at the expense of a bit of > memory and some processing overhead. After reading the specs using > read(), I allocate a 2nd buffer, copy the 1st onto 2nd using the > following simple logic: > > for each character in input buffer, > - if '\r', transform to '\n'. > - if next character is '\n', advance input pointer (ie, just skip). > - copy to output buffer > > This should handle EOL styles of \n, \r\n and \r. > > Comments? Is this worth it? I would try to write this code in the cleanest possible manner. I can't imagine that spec file reading is anywhere near the critical path for the compiler. jeff From gcc-return-8928-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 05:02:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3708 invoked by alias); 9 Aug 1999 05:02:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3685 invoked from network); 9 Aug 1999 05:02:16 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 9 Aug 1999 05:02:16 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id WAA00364; Sun, 8 Aug 1999 22:59:31 -0600 X-Mailer: exmh version 2.0.2 To: Igor Markov cc: gcc@gcc.gnu.org Subject: Re: a few quick questions (-fPIC vs -fpic) Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 08 Aug 1999 15:39:47 PDT. <37AE0733.AF5DC818@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Aug 1999 22:59:30 -0600 Message-ID: <361.934174770@upchuck.cygnus.com> From: Jeffrey A Law In message <37AE0733.AF5DC818@cs.ucla.edu>you write: > 1. Is it true that -fpic and -fPIC on Linux/i*86 > are no different? (The manual seems to imply this) That is my impression. > 2. They are difft on Solaris. > Is there a good upper bound on losses from -fPIC > measured as (a) size of the libs and executables, > (b) compile time, (c) link time, (d) load time, (e) run time > (I guess, (d) is small anyways, but all others can be > fairly big) No, it varies from architecture to architecture and from ABI to ABI. The only measure that matters anyway is the measurement for your application on your specific target. If you're really interested, compile and benchmark your application. jeff From gcc-return-8929-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 05:04:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4424 invoked by alias); 9 Aug 1999 05:04:24 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4392 invoked from network); 9 Aug 1999 05:04:21 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 9 Aug 1999 05:04:21 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id XAA00418; Sun, 8 Aug 1999 23:02:01 -0600 X-Mailer: exmh version 2.0.2 To: Dara Hazeghi cc: Toon Moene , gcc@gcc.gnu.org Subject: Re: GCC 2.95 and floating point precision Reply-To: law@cygnus.com In-reply-to: Your message of Sat, 07 Aug 1999 15:17:18 PDT. <37ACB06E.88C2014B@2xtreme.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Aug 1999 23:02:01 -0600 Message-ID: <415.934174921@upchuck.cygnus.com> From: Jeffrey A Law In message <37ACB06E.88C2014B@2xtreme.net>you write: > gcc2.95 and for most things it excels, but unless I'm much mistaken it coul > have been left in with a warning that it might generate bad code. > -fno-strict-aliasing was for the purpose of backward compatibility and it is > essential. Something of the same style for clobber would have really > simplified issues. Nope, no such way to provide backwards compatibility for the asm issue. Sorry. jeff From gcc-return-8930-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 05:07:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5781 invoked by alias); 9 Aug 1999 05:07:23 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5722 invoked from network); 9 Aug 1999 05:07:18 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 9 Aug 1999 05:07:18 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id XAA00447; Sun, 8 Aug 1999 23:04:28 -0600 X-Mailer: exmh version 2.0.2 To: Mark Klein cc: gcc@gcc.gnu.org Subject: Re: muldi3, divdi3 and remdi3 patterns Reply-To: law@cygnus.com In-reply-to: Your message of Sat, 07 Aug 1999 13:56:43 PDT. <4.1.19990807132315.00ccc670@garfield.dis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Aug 1999 23:04:28 -0600 Message-ID: <444.934175068@upchuck.cygnus.com> From: Jeffrey A Law In message <4.1.19990807132315.00ccc670@garfield.dis.com>you write: > I've got a puzzle that I've been poking at off and on for the past > number of weeks, and I guess it's time to ask for help. > > In adding muldi3, divdi3 and remdi3 instruction patterns, I find > that the compiler is choosing to do remsi3 as a widened X-Y*(X/Y) > instead of simply using the remsi3 pattern. It starts down this > path in expand_divmod when expand_mult_highpart recognizes it can > use the muldi3 pattern. Yes. This is the division by using widening multiplications. This is precisely what I would expect the compiler to do. jeff From gcc-return-8931-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 05:50:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11840 invoked by alias); 9 Aug 1999 05:50:35 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11825 invoked from network); 9 Aug 1999 05:50:32 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 9 Aug 1999 05:50:31 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id WAA10655; Sun, 8 Aug 1999 22:42:28 -0700 Message-Id: <199908090542.WAA10655@zack.bitmover.com> To: Mumit Khan cc: gcc@gcc.gnu.org Subject: Re: RFC: line endings and specs parser In-Reply-To: Message from Mumit Khan of "Sun, 08 Aug 1999 21:54:35 CDT." <199908090254.VAA28193@mercury.xraylith.wisc.edu> Date: Sun, 08 Aug 1999 22:42:28 -0700 From: Zack Weinberg Mumit Khan wrote: > Now that GCC is slowly but surely moving towards dealing with the various > types of EOLs (thanks Zack!), what do folks think about fixing specs parser > to do the same? > > The problem is that the gcc.c:read_specs() doesn't use stdio to read the > file, so all the usual conversions don't happen. [...] Whatever you do apparently has to handle \n\r as well as \r\n, \r, \n. See the lengthy discussion of this back in January: "cpp w/DOS line feeds" was the subject, and the first entry is http://www.cygnus.com/ml/egcs/1999-Jan/0783.html. What is the problem with using stdio to read the file? zw From gcc-return-8932-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 06:22:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16734 invoked by alias); 9 Aug 1999 06:22:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16719 invoked from network); 9 Aug 1999 06:22:11 -0000 Received: from adsl-216-102-199-253.dsl.snfc21.pacbell.net (HELO magnus.bothner.com) (root@216.102.199.253) by egcs.cygnus.com with SMTP; 9 Aug 1999 06:22:11 -0000 Received: by bothner.com via sendmail from stdin id (Debian Smail3.2.0.102) for gcc@gcc.gnu.org; Sun, 8 Aug 1999 23:28:06 -0700 (PDT) To: gcc@gcc.gnu.org Subject: Re: RFC: line endings and specs parser References: <199908090542.WAA10655@zack.bitmover.com> From: Per Bothner Date: 08 Aug 1999 23:28:06 -0700 In-Reply-To: Zack Weinberg's message of "Sun, 08 Aug 1999 22:42:28 -0700" Message-ID: Lines: 17 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta14) (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mumit Khan wrote: > The problem is that the gcc.c:read_specs() doesn't use stdio to read the > file, so all the usual conversions don't happen. and Zack Weinberg writes: > What is the problem with using stdio to read the file? In any case we can't count on stdio to do the "usual conversions". It should do the conversion for the host platform, though on second thought that may be enough. I.e. for program files we can't depend on the stdio for the conversions, if we want to be able to handle DOS-style files and Unix and vice versa (and I think we should). However, we have more control over specs files, and can make sure they are always in the host-local format. -- --Per Bothner bothner@pacbell.net per@bothner.com http://home.pacbell.net/bothner/ From gcc-return-8933-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 07:00:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21779 invoked by alias); 9 Aug 1999 06:59:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21764 invoked from network); 9 Aug 1999 06:59:51 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 9 Aug 1999 06:59:51 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id AAA00915 for ; Mon, 9 Aug 1999 00:57:40 -0600 X-Mailer: exmh version 2.0.2 To: gcc@gcc.gnu.org Reply-To: law@cygnus.com Subject: snapshots Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Aug 1999 00:57:40 -0600 Message-ID: <912.934181860@upchuck.cygnus.com> From: Jeffrey A Law I'm spinning a snapshot off the gcc-2.95 branch overnight. This basically picks up a variety of bugfixes that will appear in gcc-2.95.1. About mid-week I will run a snapshot off the mainline sources and I will re-enable the weekly automatic snapshots off the mainline sources. jeff From gcc-return-8934-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 08:48:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31380 invoked by alias); 9 Aug 1999 08:48:07 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31281 invoked by uid 220); 9 Aug 1999 08:47:58 -0000 Date: 9 Aug 1999 08:47:58 -0000 Message-ID: <19990809084758.31279.qmail@egcs.cygnus.com> From: law@egcs.cygnus.com To: egcs@egcs.cygnus.com Subject: egcs-ss-19990808 is now available egcs-ss-19990808 is now available on egcs.cygnus.com:/pub/egcs/snapshots/1999-08-08 (and on various mirrors, see the egcs home page for mirror sites). You'll find: egcs-19990808.tar.gz The full egcs snapshot, including all languages runtime libraries. egcs-core-19990808.tar.gz Just the C front end and core compiler. egcs-g++-19990808.tar.gz The g++ language and runtime. egcs-g77-19990808.tar.gz The g77 language and runtime. egcs-objc-19990808.tar.gz The Objective-C font end and runtime. egcs-java-19990808.tar.gz The Java font end. egcs-chill-19990808.tar.gz The Chill font end and runtime. Diffs from 19990718 are available. Note at times you may find newer directories on the server with limited permissions. These represent snapshots that have not yet been verified as correct, or are known to be incorrect. When a particular snapshot is ready for public consumption the directory permissions are relaxed, the LATEST-IS- file is updated and a message is sent to the egcs list. Using a snapshot before it's officially made available is an unwise thing to do since it may become impossible to update to an official snapshot. The "egcs_latest_snapshot" tag has been moved. You can use cvs update -regcs_latest_snapshot to update your CVS tree to the latest official snapshot. From gcc-return-8935-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 10:32:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11359 invoked by alias); 9 Aug 1999 10:31:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11342 invoked from network); 9 Aug 1999 10:31:44 -0000 Received: from sonne.darmstadt.gmd.de (141.12.62.20) by egcs.cygnus.com with SMTP; 9 Aug 1999 10:31:44 -0000 Received: from pc-topaz.darmstadt.gmd.de (pc-topaz [141.12.32.46]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id MAA29886; Mon, 9 Aug 1999 12:31:26 +0200 (MET DST) Received: from darmstadt.gmd.de (localhost [127.0.0.1]) by pc-topaz.darmstadt.gmd.de (8.8.7/8.8.7) with ESMTP id MAA29856; Mon, 9 Aug 1999 12:32:49 +0200 Message-ID: <37AEAE50.CE6A6C02@darmstadt.gmd.de> Date: Mon, 09 Aug 1999 12:32:48 +0200 From: Joerg Pommnitz Organization: GMD X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.37 i686) X-Accept-Language: de-DE MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Heavy use of C++ templates in gcc-2.95 fails Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ulrich W. Eisenecker and Krzysztof Czarnecki developed a C++ programming technique that they call Template-Metaprogramming. Sample code is available from http://www.prakinf.tu-ilmenau.de/~czarn/meta/metactrl http://www.prakinf.tu-ilmenau.de/~czarn/meta/metaxmpl.cpp And documentation from http://home.t-online.de/home/Ulrich.Eisenecker/meta.htm "metactrl" is a header file that provides control structures and "metaxmpl.cpp" is an example using metactrl. The header file claims, that // This implementation uses member templates and has been tested with the // Microsoft Visual C++ 5.0 compiler. Partial specialization and partial ordering of // templates are not used. The compilation failes with gcc-2.95. Could one of the G++ wizards at least take a look at the problem? The code looks fine to me, but I'm not a C++ language lawyer... BTW, the concept is really interesting. You might want to look at the code from pure curiosity. The authors will publish a book with "Addison Wesley" that might become a classic like "Design Patterns". It would be nice if one could use their ideas and code with gcc. -- Regards Joerg GMD-IPSI, Dolivostr. 15, Zimmer 120, D-64293 Darmstadt +49-6151-869-786 (Phone), -818 (FAX) From gcc-return-8936-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 11:12:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16010 invoked by alias); 9 Aug 1999 11:12:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15994 invoked from network); 9 Aug 1999 11:12:44 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 9 Aug 1999 11:12:44 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id EAA01153; Mon, 9 Aug 1999 04:12:43 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id EAA22529; Mon, 9 Aug 1999 04:12:43 -0700 To: Joerg Pommnitz Cc: gcc@gcc.gnu.org Subject: Re: Heavy use of C++ templates in gcc-2.95 fails References: <37AEAE50.CE6A6C02@darmstadt.gmd.de> From: Jason Merrill Date: 09 Aug 1999 04:12:42 -0700 In-Reply-To: Joerg Pommnitz's message of "Mon, 09 Aug 1999 12:32:48 +0200" Message-ID: Lines: 5 X-Mailer: Gnus v5.6.45/Emacs 20.3 The code is broken; they need to add 'typename' in various places. In future, please provide preprocessed code with a bug report. Jason From gcc-return-8937-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 11:14:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16465 invoked by alias); 9 Aug 1999 11:14:02 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16419 invoked from network); 9 Aug 1999 11:13:58 -0000 Received: from 03-134.004.popsite.net (HELO mail.masee.it) (209.12.79.134) by egcs.cygnus.com with SMTP; 9 Aug 1999 11:13:58 -0000 From: Subject: Announce your product Date: Mon, 9 Aug 1999 03:40:59 Message-Id: <466.339506.467643@mail.masee.it> LET US DO YOUR BULK E-MAIL ADVERTISING!!! TIRED OF THE "IN YOUR FACE ADS" (BANNERS)? STATISTICS SHOW THEY ARE NOT WORKING. PEOPLE ARE TIRED OF THE FORCEFUL ADS EACH AND EVERYTIME THEY CLICK ONTO A SITE. PUT YOUR AD DIRECTLY INTO THEIR MAILBOX, WHERE THEY CAN READ IT AT THEIR LEISURE. OUR CLIENTS FIND INDIVIDUAL ADS WORK AND BRING TRAFFIC TO THEIR SITE MORE THAN ANYTHING ELSE. THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS TODAY! **BEST BUY**NON-TARGETED MAILINGS** (WORLD-WIDE) 100,000 - $175 1/2 million - $450 1 million - $800 Let our company do mailing for your product/service, newsletter/report, seminar, convention or client list. Over 76 million addresses on file and NONE were purchased from other CD's. We extract our own addresses 7/24. ***Targeted mailings: *** Why pay $.01 per addresses save LOTS OF $$$, we will mail your ad or you can purchase the addresses and do your own mailing at your convience: $250 - 50,000 addresses extracted and we mail for you $150 - 25,000 addresses extracted and we mail for you Purchase the addresses, do your own mailing and save an additional 20% off any of our prices. ***SPECIAL*** 1/2 million mailed to .net and .com (US addresses only)$750. A savings of $1750. Only fresh addresses are sent. We extract when an order is placed. We DO NOT use addresses extracted prior to your order. We can extract by country, occupation, organizations, associations, product, website/domain, state or megatags (keywords). If we can not search and extract what you need, then nobody can. No one can target your mailing for less. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts department at 904-282-0945, Monday - Friday(ET). We have been serving our clients since February, 1997. Unlike other bulk mailers, you get what you pay for. Many other bulk mailers DO NOT send out the amount of emails you pay, but we send 10% more than ordered. If you want a copy of the addresses, they can be purchased for an additional $100 per 100,000. Then if you want to follow up with another mailing, you can do it yourself. Or if you want us to do a 2nd mailing to the same addresses, the cost is 1/2 of the original cost. Give us a call for more details. 904-282-0945 ==================================================== This letter can not be considered spam as long as we include contact information and a remove Link To have your name removed please go to wwwtoemail@excite.com and to discuss bulk mailings, call the above phone number. ==================================================== Sender does not accept registered mail. SCW 950-23 Blanding Boulevard, Suite 113 Orange Park, Florida 32065 From gcc-return-8938-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 11:34:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18700 invoked by alias); 9 Aug 1999 11:34: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18651 invoked from network); 9 Aug 1999 11:34:42 -0000 Received: from 98ab38cc.ipt.aol.com (HELO mail.info-unlimited.net) (152.171.56.204) by egcs.cygnus.com with SMTP; 9 Aug 1999 11:34:42 -0000 From: Subject: Do you have good credit? Date: Mon, 9 Aug 1999 06:44:57 Message-Id: <305.495065.427934@mail.info-unlimited.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Are you tired of having bad credit but don't know what you can do about it? Having a good credit rating can help you get the house or car of your dreams, afford to put yourself or a child through college or take that vacation you have been dreaming about. Check out the website below for information on how to improve your credit rating and get the credit you deserve. http://3626046468/ns/4credit/ (cut and copy or type directly into your browser) From gcc-return-8939-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 12:01:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21879 invoked by alias); 9 Aug 1999 12:01:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21855 invoked from network); 9 Aug 1999 12:01:38 -0000 Received: from sonne.darmstadt.gmd.de (141.12.62.20) by egcs.cygnus.com with SMTP; 9 Aug 1999 12:01:38 -0000 Received: from pc-topaz.darmstadt.gmd.de (pc-topaz [141.12.32.46]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id OAA02402; Mon, 9 Aug 1999 14:01:10 +0200 (MET DST) Received: from darmstadt.gmd.de (localhost [127.0.0.1]) by pc-topaz.darmstadt.gmd.de (8.8.7/8.8.7) with ESMTP id OAA29959; Mon, 9 Aug 1999 14:02:34 +0200 Message-ID: <37AEC359.11AFC104@darmstadt.gmd.de> Date: Mon, 09 Aug 1999 14:02:33 +0200 From: Joerg Pommnitz Organization: GMD X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.37 i686) X-Accept-Language: de-DE MIME-Version: 1.0 To: Jason Merrill CC: gcc@gcc.gnu.org Subject: Re: Heavy use of C++ templates in gcc-2.95 fails References: <37AEAE50.CE6A6C02@darmstadt.gmd.de> Content-Type: multipart/mixed; boundary="------------AA2FF07EA1B62FAD0371C67F" This is a multi-part message in MIME format. --------------AA2FF07EA1B62FAD0371C67F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jason Merrill wrote: > > The code is broken; they need to add 'typename' in various places. > > In future, please provide preprocessed code with a bug report. > > Jason I suspected the missing typenames. Adding typename at all the places that looked suspicious to me yields: pommnitz ~/meta>g++ -o metaxmpl metaxmpl.cpp metactrl:106: sorry, not implemented: `namespace_decl' not supported by dump_type metactrl:106: sorry, not implemented: `namespace_decl' not supported by dump_type In file included from metaxmpl.cpp:8: metactrl:107: confused by earlier errors, bailing out Seems like a known missing feature. Any workaround? Attached you will find the preprocessed input file. -- Regards Joerg GMD-IPSI, Dolivostr. 15, Zimmer 120, D-64293 Darmstadt +49-6151-869-786 (Phone), -818 (FAX) --------------AA2FF07EA1B62FAD0371C67F Content-Type: application/x-gzip; name="metaxmpl.i.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="metaxmpl.i.gz" H4sIAAjDrjcCA9U9/W/bxpI/W7j8D5sEcCRbTiw5dRLJctGkSRqgaIEmd++AvgeCoiiZDU3y 8cN2znH/9puZ/SaXlGTH7Z2L2uLufO3s7OzM7FJ5zEbs0XlY+lfnWfw0yLJHPab/e9B7jP3P qiJ/FqeBHz8LV0HxbPR09HT8LEqCuFqEz1b7+8+itCjz0D9/BOBHhAs/W+I+PZPYrT+Ps9xf nfssSsowX/pBuAUbzmReLTfg42TEGGGEV9CUsEdvHrFrg7dkFUfzKF3LoqYfibwM/bLKw2IN fpfkmyAw4w/TjSDP6EWHREc2pa2lsJFYvb2pjuJL8SxYhMs1+riVHh+z8XjcPVgE6ZJobGvk MfvueRf4ka1twnh5vA7DpTEQ7PC7DtnHCpN1KGmVVLAoqnmxyYLgXEev1nNFuFdti4LDNGXx 3ntBmiyjVU0W1iZ4+SVbu0ygHcFAm6xKimiVhAsWnPk587zKww/TZn9xluYlAdAnBwS4BOqH v47eOE1W1I0fpr0WAPolCf278heeQasOIfsfs+edmjjS3CQS24NP/mKRI77RK5nCx0V4AZ07 O8zqFrJFi9a+lbNPDD9K0lbE83QRtnYmcZR8hl5mdhu6SJfLBq4aStzs5ViZkLXRURTR/4Sy S/XBTlEFJfj7a/T5AvTCj38f/2sKLTfwtCwkyR1m2hmHXQiVWxzJ8mA+AjkfjuGV0XnY0lVc zuPPYnT/4QIIYPf7TPPMWqyOwy0X3rlffJ5y58BqC6U2dka/FRJbLgpvHpXF76PD8XPGnrH+ S7bHUIvpkvUV3GDAtKoWXhGiWDUlfQ6/WFZZW4IcKMoCMXvkNl51uQ3tf1rjAfBDz1ZBcIB/ o+OXxwcZfk6qqwNcSQh4MH76avT0+Fg75HIB0klPox0xcHl1L2yU02cms+PRvTFj7du57uKO +OhepdgkoHC6Y7GKO0MOGsD4xf0NoEtAdgm/pYRSm0cq2LoPYVjbJj462mQROZVOa/I9uurR MXlcvyzzaF6Voeexfl/4dg8dwU8fPG8wGEwduEfjNbgf67j23vse9qXbSOCisrksdZ0yp5Zx Vrtjn9ag9xsZgZ+vNoznNg3Vpf4u0miBGxhwD2A79OKo4BbNhzE6vpeBHLWEoofje2QHodaL DaYR3PLzNrCj1jUI29jLLqwNEixnD9+6mffhV++P6jzDKIoZbe8+/PxWbPr2lGKnih0IwMA6 9/PPYU7RQLN1z0sgG572Gnygp4BMe8pzZh5G0KrL0gID2dHLcYcGbqaWCETwWlJYxv6qoChI Esb/MbjaI2hI8hdeVubTHUd7mCyc7XO/COsdl3kE/qC9x8GDdziYgC6clLBdgcsuUB50Ff6F 4F7rmPvB5yqTXQ4kJMjV7pox/qGY9pyzBqSihPq4sqM4TNKpfIQIFLdafBahOAaH8EEEeFyc ei4VVDlsMHF1nkylsF6VVEW40M8ECtr4ffSvaU9ajTZMkAw/TMk0araOkntZXMGQRGnG1UlP sMyjxBvKz2lV6ocwz71pzx0NX9OARbIAwvX30GoG8KGhwaFwk0MTASCnDRJkLC00YD8uyk5K Uvv9vSIMP7eQUWBDnD+BizPZ34NsoXBzJ7AbagjS9HMUelHqLaskKCOQSiQYBpYAQlOpuwki iB000caYLkp/zlv5M6cxFXPuZMvMR2kIVi1OPYrkNYE5XcbpJQxSCsMHZ4OtB0kvmoS0Rhs/ Ji6Ar8IyMDBxB11mDSbQm1UEKLK5IVuPscSsaxPSS7DuNHeDNsQAewpoucESdmOYdVC1hSwR hazARDKl0aBVshZYiV7mX9qBO3bEGp2LZRH4ydKeQ26T5I9xtZiRDV8zTpEullkOn7egZVIx vQDp218k1sCIcXPVS+dm4hZgXHVk1DL8sXA1b+W1ERtmGp7tYdg+Q5t5KwXY0rsoWPy1BeRh KHcyH5xpYwFCFCDi6eOti/sUod38P4mum4V48UO6AgOC7RwTEdOeBjL+cdbRW9ixRiJ4/PLe QmhmZLrMrDxay8JMIlpC5eeHt5v+th+1Y+zv454RxH5RsIjjY9TEG1LZwB8V+amhYD0muSI4 GDxNWzsp/jV6tSvg/Ty8ai0rL89LHv+2FrbxMM0vQyOChhbYnMN4UfSuRT1PjQfj9DKXkboc NsSmJd+NRdx3GS3Ks6ksBQoZZCjOKVKoRwFjLAGFKBDccYlqreFVEGZiN1ecsjwMogIaeRQo c04/z/0vBc7PzdRR0Rg/39pI0ETE5IP/mrCsmsdRYGqLpxxpscvSLMz9Ms1nfXwciKgb8frc 6ctmaOV0JiS8nmalMz2BJgAOXU1cvQO4J1iPaPaYJoN9YVKdY5jEFXzd21ml6WIelWzGDtmw twPRAn8a4dPSj2L+OMbHuS9AnzN2Y9BD9lQPQYJRIrEhdpaYyAzR8GOWwceX+BGsLwkQ+hif kjQAWQnwaMwb8jCL/QBbjgl3zomPARs0iY9+/kW0WBLhpuMtIkhK2TxcwcZb5UPoWdzYGrJh 8QP8nRpVbQK4ZsXnKLssQEU0LmiPw2UJjyAmy6PVGX5+zvcy8Bx+jJCHAnQRBggJjywNCBA/ noVXBCShYHFcYrpGoAiADVkKBAlDglUZ2FnA4QBZAxYcUZELojApo2UUcHQEXEZX4ULgKXpJ hCmVQCZykP+kAumQHBnCmbq9JtWDDLQGZjC+fRjYPowILSZO/ZI6YFq0FPvEHGd/8UdVKABU 4z4pcF+qjvjgCoY1++LFrdas5abAS/UHIvC6ZnlYVhihoO9iN01I9XDhxwOAV8+YNc84Gv6e Qf9UUsM+pGbYjfB16Ooc3MkDCvYmpPichJfLQW/nWjym8WIJuhJY9AceEUhJgCBTTk+7Efzt Yk6+hTmh1SNQ97gKYEplI3DBRpKFE+F/uTSeqRIBKtmgJ1Ju2yGTdulOBHwCDhmJUysdACf0 JyYJ/Rk6+jb8AOlMeztazqyhiyIsl1oVLjXg8ZZWQ29H6OHrjNWUgIDr6Q91H52MbcgOBic+ 7bI/OeJX1scZ2uV01koCurFk2Yb77owzbWOCk0ZBgWO+ebDQAMRPYuHR3gXrChkLaP6X2TpW a69nBANeeZanlx7uXlVuLv8bAyiIQz/vy1CD/wa/R8P35KMIfdj3AmDC/37lOyEoI8IjTd63 a8Yrg4YQcrjEHNSuWKM6cciCDBgRttyJNiGtY4BufHsWODEYMzhmVSgNlGgCQ0TRCruLIc1k woMOEwnZdmD1CY1Pwlf6LCIVS0zoX8dZzKNEEgrLF1yBLchq5xAxH0+nm9BiEN/DmkSAwSGY j/jYPxhZokpSD9uo1EXUU+WQ0gibTcMwcBSZBIts3OZ1Nxg+79jaCO3UYQ80CX+ceqSMQu6B dQQr+RjIewZWTpJSAKEIyYWKTVO+tllfO0AEN+TzS4jjycV8SQLwK+UZ1X1T8kBpMpiacHxR 1QBxPdXb9JQKTOVFwcb8GIKYvk0ZuV1ZHWQduyy7TPMFCmM2G61cn7wP0z6w5hoGv8zRQNC5 vgpVeIbzAQJBoWczPWG8g4Z7o0IzgMnTMgzKcDERJgyZf4jG2TfmspijQx1aEZZXpuRlpybe RZSXFWxbfyKBWhcqPwIZbMI2UUFR5H0q/cEFroJ7T36aikoH/49+mRm8OASBbC+PLigJtU+4 YPfMI6y3NNJ+0wGLAw9uT/SRHDDWwWaigduKqWxTAHMJFHOhkz8tiIHOiWEXjJIVzZIweDYy 3csijEu/b2LvGti8VyhQlAQ0e533qnM2YTmWIqJUJKx2qyiSNHvS1h5TTN5tHgvsevxgwBzs Xl9D7IFzNeqE5VlUsH0ml2bNbsU6NEyLik2ej5G2uNckSe2yKzr5MhmLszDTyXpV4uEFNXNF M2rxEFcMiE73VlmZS98oVlstTGfgcw+vMEuEXcQ68YNpsU4yhQiccGYQNkhax5IWQnhbUXDW JvbZqU14nSgNjAxH14XBDzUtJlgk/haKJNIm5XZZ1GltTRLnbmec4prhSRwmncDswMmKLOoq q0q6n9qnol6ARrlnzfD+PriawGR4JVPCunIcQBSEAST91SkfUzkfNOn8cxlPTdkwqbCoKKSv hNUOSyUUnoaoidQM+3oydb6z1NmOQXc1r84znjg2KRm20LeMYX+WDCZ9c2Fhizm2zKCLFE2N s31IhOuh+LwvTGmobIQP0p8dDuxNIxOgmQLNDNmtBTCzGM8gh7WW1CzM6nKs+pq9cD9DcSsg XOkQi8K9mpoGzuOYPrpWULpAtBYRBpDzqeWhoGk1tTwFAq3M9QM7nTjit2xUNqr4jUqhiZDF Yc5SbkmbGRzeiyWtcExC61yDg174nju4dfTaHaVJ7fV66bSOJ6x2B8TU5OuaWI1bIY6hvF47 FDV1E2ZfJTFZ/1IfRIeY4S8OOetkcb7POH5jxq35ejjD6+FVHLMGqrjSYuGKNgcaLZqGwZvL tUoKi6wMF6hwBa4Zq+EtpvnSME0K3iCFCM4gMMZrAAKRc7KTI+4hkYzwHHbsqDKKZVwVZxjC 9B15jOrEkAS3q2WYhwstvwrFNVs5bNFDIa247UAiYQUf81nWIIK96opF393d3pWh7in7JS4o hgWjjzZgFwGdJ33jeJ0VQxMgqQ3CwsUD8v7mWBjEi2PxvjrOG+oEQ+xhMI8zSkGihJco0qrs pJep7Alb4H9NCDTsIGWYB2FU84ZYLDUEY4su0RqBk3H6T75+iMSABKIP7NTdYL/lKNq4IrLg SjRamBZ3m4gaoa1noDmZPD8NaRNTuzkSgWDPsZCwhOBaYIuUygJUhJrqXQ+FRJdjp3IM/w51 Kmcl2IAEawOXUiBDRaOrSvDqkZlKVol2Cg73NcagaQT+36rx2b7E6fXGPN6yUIUnVZi0sePJ B4Uh0YDpuvoYXGYYg483qs9j219bQnSQ4rI0ycl2PSw9B/zQC0mJze3rV0tTAzniw2lvhwiL Z2sirU2XZKZOGfAY5GdqSxpIEtwVmwO2OszIyL/glUdrVam9+8CZOZJbh43r0o/KWi3BDnIP WnIxw2+u98aauHDdAJAMHKTw5hO3W/jUSkTekZIeA0Gd5Lp8fc0JESSnZwlHOl7h2bRRbqOq OOze/A6rVZrRrbXqHHJAm5UJQrXUN7JYIoJzWNDR+VCGFbiMPWqqre9A7JE1leBtwT5s0EM8 88ZKyMCOPDCZCepTTZcR+0547ixqTMy7gG40vAFOeKKcbKYFpzPbOnd3zXuZPMnA5cAjDDyM FrypobbarMxtfygFtnOhMi2KQC04S5gTS5ZBjZ45pgu8KSgcKtn53vK8PGxc6mM+uv+02BOm xvS6NibQRYo9ffrUgLlYpvn5RvwMJCeOIKwOzJoRUfGloFFbhml0w6/2cAqRyTn0rcuOGqI9 BgJM3OCce7lz7yw8uqLcb+nEuFect0z5e/lU4aSyLy814oVRq8apy57XzWqhrkW3hd/iqo+4 kYPoMrAVnKSo8pFmaeFslGm6FT+ISfvTTW6P+WXpB2dOsnskkzErYA54dd8/D82LqWyPh1ob o/JwSFxAolhJuCsYPUYix8fPHfNjpgUbpxfa/xYeSeS8WhEmKXoVK0BZOk4CNZHvFd5EuBV5 UC7H32pndqB2/8nCBvHlbfKi2+VDdgSrVwtjPWbOFTqTWkwha7YPZ7L4bFdS8YWQejnCJPQ9 k+XziSh3N0saezR/dTKiYlMLxr6dF9zWld3Bd7Y4uk5HKb2gdb7GLa/7kM0rU9rB9eWIYg7T QLjyEuHEPlU3jotnGBjviFPaWTHn16iACKcsb3cAGL/hNHvCnoCUO+K2CV8c/BoeXyCLMKDB AIS67jM7Bmx+D5QJB9DTR5MwxPr5pGuE4rQR+kRTgww/pqS3SXqqZsrZDjBgC0E7v/9LSjLt 3fRuGLPe+9z4u274PeXuC8m18zTj+HOX9fc879xPomwg7qXqbg7PQSIJIxoNuNSESwVcquHU iw8S7rJQZECVxUC9FqAoUQ1K0cCswwUFAVi8CVDRALIvaINRysUgNnnQRO+6noktUi8tllfN rV2QMY7AZUuHKS1ccV6aIX0ZBT/kt2iamaOIS4HKgBbJwSlXGK5tdeIymt6YQS0XHbNUXGbc JOVpj7wuI+568uVDNxYGAwLGHz18e5BytgZTuxX2FePkSazrg1OeiwT64sUeBvDygpZNou7p 2J57t3Ei2HfaG5j1shJHNd3qgCd1N+0s7p0BP9D+VpSpgKXLV3Xlmd3O/UjvXmUYx1ljxnky YYaA0OCXRp6iQC9aYB3pSr4qZIFLL2NxGerkxK5YuQBsOzAT4P4ezx1PThiRGQQN0zbofBsq ljF3SO22YSpXufiaU7+e/b0Q5baadYyJn4luMFPrAKk4shElBSneG8HdIcFAwPPaKVvk1+M4 vpQp6bJYfisZq0nyWqzuowpQc+W6uHWSMVXJ6bUSnKdpzOaGQdfFmet7ey78RQpbYdg5HXTl 36qfmTw4gUHSzYb0avDqtYPKKIThm77WSqUGYeNdFi1CIkmgjmjtXB0eQ+3+XN4bFXhEmwQe 9ZtI6pXNVZBWSWkU/T0Me73LohmaRDI0mUg01j/UcUrUHac4wxQ5UMgBZX5Z5irDNIuSEGE/ +WfyxIVoObb1FAwPhdic74CwCEMUPO1RaRF39ZFGqxC7llNXXHYHgZOuUZbdfviEfCcVEIVt 1FAf6RZD7f9FU0Vj+qt0ovJ22LIQ1hFV2rC1rbiJVI/KCMsUJ2mR4r7oig35mxAkM5BOYpec xCaGXggVYwjbCo8VIMx7+Ds84UK9Y2HlQNfyjQjzJr9KjEBekRrRy2jTnshwqISwC/kNJ4yv MH79Ku+cH5waJ2EnxHtQT6gkoYdEACnppMmoOOgkzfTFgGuePYygRVyRtkZ+aJ4efoMBt43B LfkdBB99Y8FRv665mZFFNAfVIh6vWOl813wvBSST5zoPxRAG9fMilWRjbflMv0MAyas4Dpuq rJgoIZAsQevB83dWTFjBJzhTbTfm22xYDpSpltzs+aZtnaiJ7b++RPWJI0tmI3XYT8utXh3H kizr1xcspnurRn7o7N4gP1w16IvjSZGynak1Ll4WwnM9s0ogbyQYh3v6lSxZQhzoN/XMcEzx pOsL/U5W8obDXdjwA7qu1FeBXrTAtqe+qjAS1YPM01Pht6et/fUwwxGEA5R0/03PbwCZhO5C pyUkaxOaR2YtvCho2Ujku5CBNbPbIS69YONOMtvAmcTZDKWZYyp+zmFjbri7iYLXjMziuxGg Yt0KiglnJwCli13MeBq4bkbYejC2faLnIiPL45slnM4JM1NFI0/UFWqZIPKGoXwWAJQ0Wolf sygdpdtle1oMvOQgGNPbbNAGk90QCpysFsGNY30Nhj4i2AS8DSI/K3hI2/BHM/xeMjx19wK/ KE8kv1PWRxyaD3uMaccY05Yxpp1Cp/UxpmvHmN5ljGnLGOX3LrknMsBv62MmkEMTEHXAHhWE eW7Tc4HG6Qr3LMfZD94Cajn9MfbsDqjUorTu9EeQapz/iHfYPkjhI3q5EcIx+loW4yxvF7+d g07G8LIgxIRP6X14ecAoLjfAJ35ochZeidP5wIh6I5wGkyaAtdDE78i4HU3obaEJPVvQpJNI /FLS7f7FDvmd/C9q/xAIG4sv0MLWoMzjR2xk/uMgLf/Vv3jqQe8B/4NXSooMv/JFEnyA30hE Pw8QgP7BEdHANDRsdOCky1D3XeuP8keYxccwDoPy01mYsCaMZFaGMEQgeML9B0IPxUnrW8gf TpuYNS6/hUUVl+1gipE4ZyV5fnv7adqOcuPou6ED/zVjRYn/Dw0VqX7DoSr5qdb9Jk0WEV45 OF2jlDTvUImQ1DAVt7xrZVovxcnSd2vZLUyH8m7k5Q+ee1qCtShJTnTHpEtn+s5YWzXJ8C+u RbUMJxM1Oj0fkwmIDXkmdjikbxDjkIBF5nVCIpJsnJCtAzUR5qD1dbwf37774T9//gTJ8sHR +MXxi+mDO/gRTfaXKP4vP65CSfelTbemQoB+g68ptU81/36l0l8BQUn7pmOZSJ1Jyre3C3aC 4/nkr4bcCD7iHZ/zMCnF8y+w9+I7EGqCBcumobz54ePbpqmYIwMuNx0GoFjz71rBTx3QJBh9 xbTDGNYM0neP4OM/Pnx689MG5k74k0kiRcBHh6jyW7P46AUSPAzrgK3zrAwVmHwiKpKdILQW c5lW9MZln4SgOcBaqXgSy2PA2k2N3WyyZj+8O+krIWvmQtY8GD5YK6v8aRjbFrh8Dk9wrqWq TtnpenzuWxDlI72Wt+mguX4fYilzCymFLSg7H+pQZ8MfLSlJvvEIN/Cet4yuyjRrd3Dmq4hv //vtG0xguxycCR9ehUHFX8a5ubWXc3s3V9AgxvPjr01H0BxF+4gVq8lEDaBjwGhLSprJ5FMI aZ9BAqcb9r/wAtYSjmetwf34ax19qAfbhWhs5TCjHXZF9jSZcD245mUTv1ybhvom1JyWf/z0 4ee3d5uZTlVvpeT6VG8Au61672w7txkQKVlHcMO6Id7DOLcyI9OWhF28/Xflx46t24oAYvrO PfyUw6f2EB01uC5YU0qdEVnc9ZCo20O1LwUZIqbl3z6Ch3cawc9hUfyd0p/cVfi/Xf8nd9L/ e/oO3fzvHMDpN5D/b5+F09vNgi3guzw9VyHGeebn4ZAykJT+vP6yfp979+tvd93l2IngLbYE EupTamwI2+xtk8mbdBESkdO/bZ/7JkMC1RLiPsyDnB2YGXjS8/GX7nAOsxIvjrx0lF2htyoi vI6q4vSiXEybrbKSau6aMrgNz1Osq+giq2wxTepa1T2qEu8OP5JAj/AJ39MwJQeheRXE4MEL kNddQf0adkihm505rh9uz+yHjQb1+vYMXm/E4I1m8KaT3JsNtGI7peiUMXNylLVrlqJigd+f HFl2ueVgI7ds9UzakuIk2R+d8ooOfZd/3ZZUOKrFbU3vmv7U3gpq42XGJtA3g13ck48GtRXq tDyU8B2Wlt07Fum+XjADf9rt4x2a3kbjzhDatUx/AeWEi28kPo9niaJhYesOITifP047imFO vpsUHDrUuJFan3x9gn/+mG5RwsIvH8Gc4I/B5kiSacs0tv3QvTaJ++Sf5ZMNcG+2PYJxxVhb GSruutH+aIih9vC7IXyq2chpxxa5oYZa1in/asGI9jazgNWrk32EXgI3UcioT13+FdrBCMOh 3AiHcosSZxPR0svp1GJaZwGYdN7ThmpGQAJzI0lFvdMpregbDVvrzFizh/4fHOEOdY2Hr9u6 ROl4+OaU0X8arCOik45f8VVcXDTx37vg/wiQLb0Y13ioAFp06PpxKFXQe/WqTlB+RZs9p3V6 G83Tj7+65wja7V3w8HRo7XbOZdGO/upVF/5GovLqj1Na3mXRH9bFZ90SrycBQ2DbS43+xSkz dowOhyK/HI6GB+Oh2K01l7U2Ii0XqR0aTszaPk/xZUkvTtNsauLKxhZu66xKXbIGh9b7X4Ng Tm+UhQAA --------------AA2FF07EA1B62FAD0371C67F-- From gcc-return-8940-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 12:36:17 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5216 invoked by alias); 9 Aug 1999 12:36:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5180 invoked from network); 9 Aug 1999 12:36:08 -0000 Received: from 98a9dbc6.ipt.aol.com (HELO mail01.homewknow.com) (152.169.219.198) by egcs.cygnus.com with SMTP; 9 Aug 1999 12:36:08 -0000 From: Subject: Lose 30 Pounds In 30 Days, Money Back Guarantee! Date: Mon, 9 Aug 1999 00:59:47 Message-Id: <212.9963.46821@mail01.homewknow.com> *****AMAZING MELT AWAY FAT ABSORBER CAPSULES***** LOSE 30 POUNDS IN 30 DAYS... GUARANTEED!!! All Natural Weight-Loss Program, Speeds Up The Metabolism Safely Rated #1 In Both Categories of SAFETY & EFFECTIVENESS In (THE USA TODAY) WE'LL HELP YOU GET THINNER IN WINTER!!! WE'RE GOING TO HELP YOU LOOK GOOD, FEEL GOOD AND TAKE CONTROL IN 2000 This is the easiest, fastest, and most effective way to lose both pounds and inches permanently!!! This weight loss program is designed specifically to "boost" weight-loss efforts by assisting body metabolism, and helping the body's ability to manage weight. A powerful, safe, 30 Day Program. This is one program you won't feel starved on. Complete program for one amazing low price! Program includes: BONUS AMAZING FAT ABSORBER CAPSULES, 30 DAY - WEIGHT REDUCTION PLAN, PROGRESS REPORT, AND MUCH MORE!!! SPECIAL BONUS..."FAT ABSORBERS", AS SEEN ON TV With every order...AMAZING MELT AWAY FAT ABSORBER CAPSULES with directions (1 Month Supply, Absolutely Free ) ...With these capsules you can eat what you enjoy, without the worry of fat in your diet. 2 to 3 capsules 15 minutes before eating or snack, and the fat will be absorbed and passed through the body without the digestion of fat into the body. You will be losing by tomorrow! Don't Wait, visit our web page below, and join now! http://pages.hotbot.com/health/weightlossnow/ From gcc-return-8941-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 14:52:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29423 invoked by alias); 9 Aug 1999 14:52:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29399 invoked from network); 9 Aug 1999 14:52:15 -0000 Received: from garfield.dis.com (199.4.97.30) by egcs.cygnus.com with SMTP; 9 Aug 1999 14:52:15 -0000 Received: from garfield (199.4.97.30) by garfield.dis.com (EMWAC SMTPRS 0.81) with SMTP id ; Mon, 09 Aug 1999 07:52:12 -0700 Message-Id: <4.1.19990809074734.00cdecc0@garfield.dis.com> X-Sender: mark@garfield.dis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 09 Aug 1999 07:52:12 -0700 To: law@cygnus.com From: Mark Klein Subject: Re: muldi3, divdi3 and remdi3 patterns Cc: gcc@gcc.gnu.org In-Reply-To: <444.934175068@upchuck.cygnus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:04 PM 8/8/99 -0600, Jeffrey A Law wrote: > > In adding muldi3, divdi3 and remdi3 instruction patterns, I find > > that the compiler is choosing to do remsi3 as a widened X-Y*(X/Y) > > instead of simply using the remsi3 pattern. It starts down this > > path in expand_divmod when expand_mult_highpart recognizes it can > > use the muldi3 pattern. >Yes. This is the division by using widening multiplications. This is >precisely what I would expect the compiler to do. So even though $$remoI is faster than the combination of $$mulo2I and the shifting, on PA we'll get the less efficient implementation? I don't quite understand how the current costs have been allocated .. is there a way to influence this such that I'll use the modulo millicode instead of the multiply/divide? Regards, M. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available From gcc-return-8942-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 16:25:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9200 invoked by alias); 9 Aug 1999 16:25:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9184 invoked from network); 9 Aug 1999 16:25:54 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 9 Aug 1999 16:25:54 -0000 Received: from marathon.synopsys.com (marathon.synopsys.com [146.225.100.41]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id JAA24926; Mon, 9 Aug 1999 09:24:31 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by marathon.synopsys.com (8.8.8/8.8.8) with SMTP id JAA10267; Mon, 9 Aug 1999 09:24:22 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id JAA29949; Mon, 9 Aug 1999 09:24:22 -0700 Message-Id: <199908091624.JAA29949@atrus.synopsys.com> Subject: Re: a barely useful option? To: dietmar.kuehl@claas-solutions.de (Dietmar Kuehl) Date: Mon, 9 Aug 99 9:24:22 PDT Cc: imarkov@cs.ucla.edu, gcc@gcc.gnu.org In-Reply-To: <3.0.32.19990808161644.0093e050@mail.omnilink.net>; from "Dietmar Kuehl" at Aug 8, 99 4:16 pm X-Mailer: ELM [version 2.3 PL11] [ Usefulness of -Weffc++ ] For a snapshot or two, -Wall on C++ code implied -Weffc++. I convinced Jason to take it out again with roughly the argument below. Note that this argument doesn't apply to all the -Weffc++ warnings, only to certain ones. > With a reasonably implemented standard library this options is quite > useful! My implementation of the IOStream library currently issues only > warnings if deprecated library features are used even with maximum warning > level (-W -Wall -Weffc++ -ansi -pedantic). While any given piece of code can be improved in this respect, it would be a very bad idea for any organization to mandate no -Weffc++ warnings, as there are some cases where the only way to achieve this is to make one's code substantially worse. Example: you decide to write a set of template classes to handle reference counting, using the envelope and letter pattern. We want to use templates, but we also don't wnat object code bloat. So the design looks like class BaseRefCountRep the base representation object. It has one field, a reference count, and has a virtual destructor. class BaseRefCount the base envelope object. It has one field, a pointer to BaseRefCountRep. Its assignment operator, copy constructor, and destructor implement the usual reference counting; the BaseRefCountRep is deleted when the reference count drops to zero. template class RefCount privately derived from BaseRef. There are no additional data fields. We assure that the pointed-to BaseRefCountRep is actually a RefCountRep. template class RefCountRep privately derived from BaseRefCount. It has an additional data field, a T. One problem with this design is that, because of the lack of overloaded operator dot, we can't make a RefCount look just like a T. It's still posssible, though, to derive from RefCount a class that forwards methods to the representation object. So what's the problem? The problem is that BaseRefCount does not have a virtual destructor. *This is deliberate.* What it means is that, at the implementation level, a RefCount is only a pointer. This means that it can be passed around in a register, that the ADDRESSOF optimizations present in GNU C++ will greatly improve inline functions that use the class, etc. But -Weffc++ will not shut up until this is changed. It requires that any derived-from object have a virtual destructor. But that is neither needed nor wanted in this case: we *want* the base destructor to be used for all derived classes, because it would never make sense for any of the derived classes to be anything but a pointer! (Yes, someone could misuse the class. But we simply document the class explaining how it is to be used). Note that -Wall already warns about classes that have virtual functions but no virtual destructor. But -Weffc++ warns about any base class that has a non-virtual destructor, in all cases. At the least, it makes no sense to issue this warning in the case of private derivation, because in that case no user will associate a Derived with a Base reference (only code implementing the class can do that). If the implementation were effortless, the warning could be put in but modified to behave as follows: OK, so the base class has a non-virtual destructor. Consider this code: Base* b = new Derived(constructor-args); .... delete b; will the right thing happen? Well, if Derived has no additional data members and does not declare a destructor, the right thing does happen, so the compiler should never issue a warning in such a case. virtual destructor > > useful, I am not sure whether it's the option that can be removed or > > the stdlibc++ fixed according to Scott Meyers' Effective C++ books. > > I think the library should be fixed. In any case, even if the library is > not fixed, the warning should not be removed: There will be a library which > will not cause any warnings and especially new users of C++ will benefit > from this warning. > > Regards, > Dietmar > From gcc-return-8943-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 16:56:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12132 invoked by alias); 9 Aug 1999 16:56:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12114 invoked from network); 9 Aug 1999 16:56:34 -0000 Received: from thor.xraylith.wisc.edu (198.150.6.11) by egcs.cygnus.com with SMTP; 9 Aug 1999 16:56:34 -0000 Received: from mercury.xraylith.wisc.edu (mercury.xraylith.wisc.edu [128.104.182.221]) by thor.xraylith.wisc.edu (8.9.1a/8.9.1) with ESMTP id LAA10828; Mon, 9 Aug 1999 11:56:23 -0500 Received: from mercury.xraylith.wisc.edu (localhost [127.0.0.1]) by mercury.xraylith.wisc.edu (8.8.7/8.8.7) with ESMTP id LAA30395; Mon, 9 Aug 1999 11:56:27 -0500 Message-Id: <199908091656.LAA30395@mercury.xraylith.wisc.edu> To: Zack Weinberg cc: gcc@gcc.gnu.org Subject: Re: RFC: line endings and specs parser In-Reply-To: Your message of "Sun, 08 Aug 1999 22:42:28 PDT." <199908090542.WAA10655@zack.bitmover.com> Date: Mon, 09 Aug 1999 11:56:27 -0500 From: Mumit Khan Zack Weinberg writes: > > Whatever you do apparently has to handle \n\r as well as \r\n, \r, \n. > See the lengthy discussion of this back in January: > "cpp w/DOS line feeds" was the subject, and the first entry is > http://www.cygnus.com/ml/egcs/1999-Jan/0783.html. Thanks! I'd forgotten about '\n\r' sequence. > > What is the problem with using stdio to read the file? > It's just the way the specs parser is written. Besides, as Per Bothner pointed out, even that won't guarantee the correct conversions. Regards, Mumit From gcc-return-8944-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 16:59:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13070 invoked by alias); 9 Aug 1999 16:59:37 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13047 invoked from network); 9 Aug 1999 16:59:36 -0000 Received: from thor.xraylith.wisc.edu (198.150.6.11) by egcs.cygnus.com with SMTP; 9 Aug 1999 16:59:36 -0000 Received: from mercury.xraylith.wisc.edu (mercury.xraylith.wisc.edu [128.104.182.221]) by thor.xraylith.wisc.edu (8.9.1a/8.9.1) with ESMTP id LAA10841; Mon, 9 Aug 1999 11:59:26 -0500 Received: from mercury.xraylith.wisc.edu (localhost [127.0.0.1]) by mercury.xraylith.wisc.edu (8.8.7/8.8.7) with ESMTP id LAA30418; Mon, 9 Aug 1999 11:59:30 -0500 Message-Id: <199908091659.LAA30418@mercury.xraylith.wisc.edu> To: Per Bothner cc: gcc@gcc.gnu.org Subject: Re: RFC: line endings and specs parser In-Reply-To: Your message of "08 Aug 1999 21:32:22 PDT." Date: Mon, 09 Aug 1999 11:59:30 -0500 From: Mumit Khan Per Bothner writes: > > You could always do the transformation in place - just use two > pointers into the same buffer. You do an initial scan looking for > the first '\r': If none is found, you're done; otherwise, start > copying (in place) from there. That was my first attempt. However, as I mentioned earlier, the logic gets really messy. Of course, one could simply rewrite the loops and fix that, but that implies work ;-) > (I tend to prefer to do the processing "as you read" - i.e. whoever is > parsing the specs file should do handle any of the conventions. However, > it can be difficult to do that cleanly, and often it is faster to do a pre-pa > ss.) So do I. Any objection to reading character at a time and stuff it into a buffer (while processing these EOL issues), instead of reading the whole bit into the buffer in one shot? Regards, Mumit From gcc-return-8945-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 17:25:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17512 invoked by alias); 9 Aug 1999 17:25:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17494 invoked from network); 9 Aug 1999 17:25:29 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 9 Aug 1999 17:25:29 -0000 Received: from rtl.cygnus.com (rtl.cygnus.com [205.180.230.21]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA22336; Mon, 9 Aug 1999 10:25:24 -0700 (PDT) From: Michael Meissner Received: (meissner@localhost) by rtl.cygnus.com (8.6.12/8.6.4) id NAA21888; Mon, 9 Aug 1999 13:25:24 -0400 Date: Mon, 9 Aug 1999 13:25:24 -0400 Message-Id: <199908091725.NAA21888@rtl.cygnus.com> To: khan@xraylith.wisc.EDU, zack@bitmover.com Subject: Re: RFC: line endings and specs parser Cc: gcc@gcc.gnu.org | Zack Weinberg writes: | > | > Whatever you do apparently has to handle \n\r as well as \r\n, \r, \n. | > See the lengthy discussion of this back in January: | > "cpp w/DOS line feeds" was the subject, and the first entry is | > http://www.cygnus.com/ml/egcs/1999-Jan/0783.html. | | Thanks! I'd forgotten about '\n\r' sequence. | | > | > What is the problem with using stdio to read the file? | > | | It's just the way the specs parser is written. Besides, as Per Bothner | pointed out, even that won't guarantee the correct conversions. I'm coming into the discussion late, but any rewriting of the specs parser needs to fix the bug that trips up anybody who edits specs files by hand, namely requiring an extra blank line at the end file. Also, it *MUST* handle lines of any length, since specs tend to get rather large. -- Michael Meissner, Cygnus Solutions PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886 email: meissner@cygnus.com phone: 978-486-9304 fax: 978-692-4482 From gcc-return-8946-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 18:19:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23232 invoked by alias); 9 Aug 1999 18:19:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23141 invoked from network); 9 Aug 1999 18:18:56 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 9 Aug 1999 18:18:56 -0000 Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id OAA12035; Mon, 9 Aug 1999 14:18:50 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com by world.std.com (TheWorld/Spike-2.0) id AA21844; Mon, 9 Aug 1999 14:17:09 -0400 Received: (qmail 26325 invoked by uid 500); 9 Aug 1999 18:16:51 -0000 Date: 9 Aug 1999 18:16:50 -0000 Message-Id: <19990809181650.26324.qmail@deer> To: meissner@cygnus.com Cc: khan@xraylith.wisc.EDU, zack@bitmover.com, gcc@gcc.gnu.org Cc: craig@jcb-sc.com In-Reply-To: <199908091725.NAA21888@rtl.cygnus.com> (message from Michael Meissner on Mon, 9 Aug 1999 13:25:24 -0400) Subject: Re: RFC: line endings and specs parser References: <199908091725.NAA21888@rtl.cygnus.com> >I'm coming into the discussion late, but any rewriting of the specs parser >needs to fix the bug that trips up anybody who edits specs files by hand, >namely requiring an extra blank line at the end file. Also, it *MUST* handle >lines of any length, since specs tend to get rather large. Indeed. Any design for something that appears to be a plaintext file is best done such that an ordinary printout or dumb-tty display of the file contains all the information a reader needs to determine the semantic content of that file. While that doesn't "solve" the problems surrounding very long lines by itself (though simple tools to at least mark where they occur in a printout might alleviate those), it does solve many other problems. For example, this design guideline forbids distinguishing spaces from tabs (assuming TAB always means tab to next eighth column, a la the default behavior of `expand'), as well as distinguishing formfeeds from blank lines. It also forbids assigning semantic value to trailing spaces or blank lines. And it pretty much mandates rejecting characters that aren't ordinary ASCII printing characters, except for space, tab, and newline. Ideally, it would also forbid assigning semantic value to the number of contiguous blank lines; to leading blank lines; to any given number of leading spaces (preceding the first printing character on a line) throughout the file, perhaps to leading spaces at all; and, most strictly, to blank lines entirely, since when they appear at the tops or bottoms of pages in printouts or on displays, readers are unlikely to notice them. While "perfect" conformance to these guidelines might be difficult or impossible in some cases (because of collision with other usability rules, e.g. users will clearly expect an embedded blank line to have the significance it has vis-a-vis HTML and GNU texinfo, or similar, formats), I suggest they be followed as scrupulously as possible. Underlying all of the above is a simple principle: the burden of making the meanings of plaintext files clear rests first and foremost on the designers (writers) of the plaintext file format and of the plaintext files themselves, *not* on the readers of those files. So if anyone has to use "special" tools to cope with files you design, make sure it's the authors of those files, not the readers. Let the readers use the ordinary tools existing systems already provide, and get clear, understandable, and (most importantly) hard-to-misunderstand, results from their decoding of such files. Leave it up to the writers to use whatever tools make authoring those files easier for them. tq vm, (burley) From gcc-return-8947-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 19:26:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1001 invoked by alias); 9 Aug 1999 19:26:46 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 884 invoked from network); 9 Aug 1999 19:26:36 -0000 Received: from maniac.deathstar.org (0@204.42.254.10) by egcs.cygnus.com with SMTP; 9 Aug 1999 19:26:36 -0000 Received: from maniac.deathstar.org (localhost [127.0.0.1]) by maniac.deathstar.org (8.9.1/8.9.1a) with ESMTP id PAA18445 for ; Mon, 9 Aug 1999 15:26:34 -0400 (EDT) Message-Id: <199908091926.PAA18445@maniac.deathstar.org> To: gcc@gcc.gnu.org Subject: Re: a barely useful option? From: Sol Foster Date: Mon, 09 Aug 1999 15:26:34 -0400 X-Sender: colomon@maniac.deathstar.org Joe Buck writes: > If the implementation were effortless, the warning could be put in but > modified to behave as follows: OK, so the base class has a non-virtual > destructor. Consider this code: > > Base* b = new Derived(constructor-args); > .... > delete b; > > will the right thing happen? Well, if Derived has no additional data > members and does not declare a destructor, the right thing does happen, so > the compiler should never issue a warning in such a case. My understanding is that doing this results in undefined behavior according to the standard. I can't cite the standard on this, alas, but the C++ FAQ claims that a virtual destructor *is* required if the base class destructor is non-trivial. It may work in GCC, but there are no guarantees in other compilers, and so it is exactly the sort of thing one would like to be warned about. -- Sol Foster: colomon@ralf.org HarmonyWare, Inc: http://www.harmonyware.com From gcc-return-8948-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 19:56:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4684 invoked by alias); 9 Aug 1999 19:56:20 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4569 invoked from network); 9 Aug 1999 19:56:09 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 9 Aug 1999 19:56:09 -0000 Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id PAA00034; Mon, 9 Aug 1999 15:56:06 -0400 (EDT) Received: from localhost by world.std.com (TheWorld/Spike-2.0) id AA11082; Mon, 9 Aug 1999 15:56:06 -0400 Date: Mon, 9 Aug 1999 15:56:06 -0400 From: Steven W Orr Reply-To: steveo@world.std.com To: gcc@gcc.gnu.org Subject: Does anyone know about something called asmerge? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm looking for a tool that will interleave c code with the resulting assembler. I remember that there used to be such a beast years ago. Anyone have anything that smells like this? Please email response to steveo@world.std.com thanks -- ----------Time flies like the wind. Fruit flies like a banana.---------------- --------Stranger things have happened but none stranger than this.------------- Steven W. Orr steveo@world.std.com ---------------"Listen to me! We are all individuals."------------------------- From gcc-return-8949-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 19:56:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4811 invoked by alias); 9 Aug 1999 19:56:37 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4724 invoked from network); 9 Aug 1999 19:56:26 -0000 Received: from 209-249-66-150.snj0.flashcom.net (HELO ocean.lucon.org) (postfix@209.249.66.150) by egcs.cygnus.com with SMTP; 9 Aug 1999 19:56:26 -0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id B138A57B9; Mon, 9 Aug 1999 12:56:03 -0700 (PDT) Subject: binutils 2.9.5.0.6 is released To: linux-gcc@vger.rutgers.edu (linuxgcc), kjahds@kjahds.com (Kenneth Albanowski), lmfken@lmf.ericsson.se (Kenneth Osterberg), mat@lcs.mit.edu (Mat Hostetter), doughera@lafcol.lafayette.edu (Andy Dougherty), brian@mathworks.com (Brian Bourgault), imp@village.org (Warner Losh), meissner@cygnus.com (Michael Meissner), rfg@monkeys.com (Ron Guilmette), linux-binutils-in@polstra.com (John Polstra), galenh@micron.net (Galen Hazelwood), ralf@informatik.uni-koblenz.de (Ralf Baechle), linas@linas.org (Linas Vepstas), aries@hal2000.terra.vein.hu (Feher Janos) Date: Mon, 9 Aug 1999 12:56:03 -0700 (PDT) Cc: libc-hacker@sourceware.cygnus.com (GNU C Library), egcs@egcs.cygnus.com X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990809195603.B138A57B9@ocean.lucon.org> From: hjl@lucon.org (H.J. Lu) This is the beta release of binutils 2.9.5.0.6 for Linux, which is based on binutils 1999 0809 plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. Please report any bugs related to binutils 2.9.5.0.6 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.5.0.6.tar.gz. Source code. 2. binutils-2.9.5.0.5-2.9.5.0.6.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.5.0.6-1.src.rpm. Source RPM. 4. binutils-2.9.5.0.6-1.i386.rpm. Binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 08/09/99 From gcc-return-8950-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 20:08:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6859 invoked by alias); 9 Aug 1999 20:08:11 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6842 invoked from network); 9 Aug 1999 20:08:04 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 9 Aug 1999 20:08:04 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA04800; Mon, 9 Aug 1999 13:08:04 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id NAA32057; Mon, 9 Aug 1999 13:08:03 -0700 To: steveo@world.std.com Cc: gcc@gcc.gnu.org Subject: Re: Does anyone know about something called asmerge? References: From: Jason Merrill Date: 09 Aug 1999 13:08:03 -0700 In-Reply-To: Steven W Orr's message of "Mon, 9 Aug 1999 15:56:06 -0400" Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Steven W Orr writes: > I'm looking for a tool that will interleave c code with the resulting > assembler. I remember that there used to be such a beast years ago. > Anyone have anything that smells like this? GNU as will do that. Check out the -a option. Jason From gcc-return-8951-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 21:01:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14562 invoked by alias); 9 Aug 1999 21:01:12 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14518 invoked from network); 9 Aug 1999 21:01:08 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 9 Aug 1999 21:01:08 -0000 Received: from marathon.synopsys.com (marathon.synopsys.com [146.225.100.41]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id OAA20089; Mon, 9 Aug 1999 14:00:23 -0700 (PDT) Received: from atrus.synopsys.com (atrus.synopsys.com [146.225.121.23]) by marathon.synopsys.com (8.8.8/8.8.8) with SMTP id OAA09748; Mon, 9 Aug 1999 14:00:22 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id OAA19728; Mon, 9 Aug 1999 14:00:22 -0700 Message-Id: <199908092100.OAA19728@atrus.synopsys.com> Subject: Re: a barely useful option? To: colomon@ralf.org (Sol Foster) Date: Mon, 9 Aug 99 14:00:17 PDT Cc: gcc@gcc.gnu.org In-Reply-To: <199908091926.PAA18445@maniac.deathstar.org>; from "Sol Foster" at Aug 9, 99 3:26 pm X-Mailer: ELM [version 2.3 PL11] > Joe Buck writes: > > If the implementation were effortless, the warning could be put in but > > modified to behave as follows: OK, so the base class has a non-virtual > > destructor. Consider this code: > > > > Base* b = new Derived(constructor-args); > > .... > > delete b; > > > > will the right thing happen? Well, if Derived has no additional data > > members and does not declare a destructor, the right thing does happen, so > > the compiler should never issue a warning in such a case. Sol Foster writes: > My understanding is that doing this results in undefined behavior > according to the standard. I can't cite the standard on this, alas, but > the C++ FAQ claims that a virtual destructor *is* required if the base > class destructor is non-trivial. You are correct that the standard reads that way. I challenge anyone to name an existing C++ compiler in which the right thing does not happen. Given the fact that the GNU, Microsoft, KAI, HP, Sun, SGI, Borland, etc compilers all have this property, it is nonsensical to ask programmers to make their code substantially worse in order to satisfy language lawyers on this particular point. Possibly the -pedantic flag should issue the warning, since the undefined behavior is only theoretical. It certainly doesn't belong in -Wall. There was a similar issue on whether vector elements are guaranteed contiguous or not, it ended up getting settled by a defect report. I suspect that at least some of the committee would feel the same way on this one: Given that: 1. We have nonvirtual Base::~Base. 2. We have a derived class with no additional members (single nonvirtual inheritance) that does not declare Derived::~Derived 3. Someone writes code like the above (deletes a Derived object through a Base pointer) come up with an argument that the behavior is undefined is not equivalent to "that's what the standard says". For every existing compiler Base::~Base will get called and the right thing will happen. I claim that such code is completely portable. If you disagree, you need to show me a compiler *that someone might actually want to use* in which something different happens. > It may work in GCC, but there are no guarantees in other compilers, and > so it is exactly the sort of thing one would like to be warned about. No, people do not want to be told to make their code worse. I have code for which I expect a 3x performance penalty if I take the Effective C++ style recommendation here. From gcc-return-8952-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 21:05:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15921 invoked by alias); 9 Aug 1999 21:05:06 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15904 invoked from network); 9 Aug 1999 21:05:00 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 9 Aug 1999 21:05:00 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id XAA06488; Mon, 9 Aug 1999 23:00:19 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id WAA00772; Mon, 9 Aug 1999 22:57:35 +0200 Date: Mon, 9 Aug 1999 22:57:35 +0200 Message-Id: <199908092057.WAA00772@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: pommnitz@darmstadt.gmd.de CC: jason@cygnus.com, gcc@gcc.gnu.org In-reply-to: <37AEC359.11AFC104@darmstadt.gmd.de> (message from Joerg Pommnitz on Mon, 09 Aug 1999 14:02:33 +0200) Subject: Re: Heavy use of C++ templates in gcc-2.95 fails References: <37AEAE50.CE6A6C02@darmstadt.gmd.de> <37AEC359.11AFC104@darmstadt.gmd.de> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > metactrl:106: sorry, not implemented: `namespace_decl' not supported by dump_type [...] > Seems like a known missing feature. Any workaround? Perhaps using the right compiler? The attached preprocessor output says # 1 "/usr/local/egcs/1.1.2/include/g++/iostream" 1 3 I somehow doubt that this is a 2.95 installation... Regards, Martin From gcc-return-8953-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 09 21:12:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17793 invoked by alias); 9 Aug 1999 21:12:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17677 invoked from network); 9 Aug 1999 21:12:41 -0000 Received: from sonne.darmstadt.gmd.de (141.12.62.20) by egcs.cygnus.com with SMTP; 9 Aug 1999 21:12:41 -0000 Received: from darmstadt.gmd.de (ploesser-isdn [141.12.156.219]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id XAA25707; Mon, 9 Aug 1999 23:11:47 +0200 (MET DST) Message-ID: <37AF432D.105BE4F2@darmstadt.gmd.de> Date: Mon, 09 Aug 1999 23:07:57 +0200 From: Joerg Pommnitz X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Martin v. Loewis" CC: jason@cygnus.com, gcc@gcc.gnu.org Subject: Re: Heavy use of C++ templates in gcc-2.95 fails References: <37AEAE50.CE6A6C02@darmstadt.gmd.de> <37AEC359.11AFC104@darmstadt.gmd.de> <199908092057.WAA00772@mira.isdn.cs.tu-berlin.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Martin v. Loewis" wrote: > > > metactrl:106: sorry, not implemented: `namespace_decl' not supported by dump_type > [...] > > Seems like a known missing feature. Any workaround? > > Perhaps using the right compiler? The attached preprocessor output > says > > # 1 "/usr/local/egcs/1.1.2/include/g++/iostream" 1 3 > > I somehow doubt that this is a 2.95 installation... Argh... You are right. I just checked where I did the test. I used the wrong window to actually generate the test case. I had two windows open, one with an egcs-1.1.2 installation and one with gcc-2.95 for comparison. Both installation failed to compile the code, however the error messages are different. I will redo the test case tomorrow. Once again, I'm sorry for the current confusion. regards Joerg From gcc-return-8954-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 02:25:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18390 invoked by alias); 10 Aug 1999 02:25:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18375 invoked from network); 10 Aug 1999 02:25:12 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 10 Aug 1999 02:25:12 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id TAA27610; Mon, 9 Aug 1999 19:25:08 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id TAA07747; Mon, 9 Aug 1999 19:25:08 -0700 Date: Mon, 9 Aug 1999 19:25:08 -0700 From: Richard Henderson To: Igor Markov Cc: gcc@gcc.gnu.org Subject: Re: a few quick questions (-fPIC vs -fpic) Message-ID: <19990809192508.A7731@cygnus.com> References: <37AE0733.AF5DC818@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <37AE0733.AF5DC818@cs.ucla.edu>; from Igor Markov on Sun, Aug 08, 1999 at 03:39:47PM -0700 On Sun, Aug 08, 1999 at 03:39:47PM -0700, Igor Markov wrote: > 1. Is it true that -fpic and -fPIC on Linux/i*86 > are no different? Yes. > 2. They are difft on Solaris. > Is there a good upper bound on losses from -fPIC > measured as (a) size of the libs and executables, > (b) compile time, (c) link time, (d) load time, (e) run time (b) (c) and (d) should be near identical. For (a) and (e), a hard upper bound is 3x -- -fpic looks like ld [%l7+%lo(foo)], address vs sethi %hi(foo),tmp add tmp,%lo(foo),tmp ld [%l7+tmp], address In practice, 3x is never reached, because address loads are not exclusively what a program does. How much the practical impact is, I don't know. r~ From gcc-return-8955-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 02:31:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19542 invoked by alias); 10 Aug 1999 02:31:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19527 invoked from network); 10 Aug 1999 02:31:41 -0000 Received: from alecto.physics.uiuc.edu (130.126.8.20) by egcs.cygnus.com with SMTP; 10 Aug 1999 02:31:41 -0000 Received: from localhost (menscher@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) with SMTP id VAA29014 for ; Mon, 9 Aug 1999 21:31:39 -0500 (CDT) X-Authentication-Warning: alecto.physics.uiuc.edu: menscher owned process doing -bs Date: Mon, 9 Aug 1999 21:31:39 -0500 (CDT) From: Damian Menscher X-Sender: menscher@alecto.physics.uiuc.edu To: gcc@gcc.gnu.org Subject: Compiler glitch with tree_list ?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII First, let me say I really don't know what I'm doing here. But, I think I may have stumbled into something that's wrong with the compiler. When compiling with gcc-2.95, I got the message: pcfarm9: [18:50] [11] ~>canc *.C -Wno-non-template-friend inversionAlgs.C:29: sorry, not implemented: `tree_list' not supported by dump_type inversionAlgs.C: In function `int minimal_residual(define_field_list *&, define_field_list *&, define_field_list *&, define_field_list *&, define_field_list *&, define_field_list *&, define_field_list *&, int, float, float)': inversionAlgs.C:29: ANSI C++ prohibits conversion from `()' to `(...)' Now, I don't know what a tree_list is, but after grepping through the source code to gcc for a while, I can say that "TREE_LIST" occurs several times, which leads me to believe it should be supported by dump_type. Am I getting this error message in error? (I'm thinking it may be a problem of "tree_list" vs. "TREE_LIST".) What *is* a tree_list anyway? Is there a workaround? TIA, Damian Menscher -- --==## Grad. student & Sys. Admin. @ U. Illinois at Urbana-Champaign ##==-- --==## www.uiuc.edu/~menscher/ Ofc:(217)333-0038 ##==-- --==## Physics Dept, 1110 W Green, Urbana IL 61801 Fax:(217)333-9819 ##==-- From gcc-return-8956-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 05:15:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31974 invoked by alias); 10 Aug 1999 05:14:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31941 invoked from network); 10 Aug 1999 05:14:41 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 10 Aug 1999 05:14:41 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id HAA10267; Tue, 10 Aug 1999 07:11:20 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id HAA00472; Tue, 10 Aug 1999 07:10:42 +0200 Date: Tue, 10 Aug 1999 07:10:42 +0200 Message-Id: <199908100510.HAA00472@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: menscher@uiuc.edu CC: gcc@gcc.gnu.org In-reply-to: (message from Damian Menscher on Mon, 9 Aug 1999 21:31:39 -0500 (CDT)) Subject: Re: Compiler glitch with tree_list ?? References: User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > Now, I don't know what a tree_list is, but after grepping through the > source code to gcc for a while, I can say that "TREE_LIST" occurs several > times, which leads me to believe it should be supported by dump_type. Am > I getting this error message in error? (I'm thinking it may be a problem > of "tree_list" vs. "TREE_LIST".) > > What *is* a tree_list anyway? Is there a workaround? A tree_list is an internal data structure of gcc, and if it says that dump_type does not support it, then it either means that dump_type should not be called with it, or that dump_type should support it. Anyway, please submit a bug report, following the instructions in http://egcs.cygnus.com/faq.html#bugreport Regards, Martin From gcc-return-8957-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 07:19:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10779 invoked by alias); 10 Aug 1999 07:19:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10716 invoked from network); 10 Aug 1999 07:19:07 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 10 Aug 1999 07:19:07 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990810071856.EMIE9770.mail.rdc1.md.home.com@home.com> for ; Tue, 10 Aug 1999 00:18:56 -0700 Message-ID: <37AFD2B7.15891BA0@home.com> Date: Tue, 10 Aug 1999 03:20:23 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: C++ Error message question and suggestion. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ONE What does "`const basic_rcon::pair *' is not a class, struct, or union type" as given by: map_repl-t.hh: In function `struct find_substr_return,const basic_rcon::pair *> find_substr, filter_fitr_endf, const basic_rcon::pair *>(filter_fitr, const filter_fitr_endf &, const basic_rcon::pair *, const basic_rcon::pair *)': map_repl-t.hh:75: instantiated from `map_repl::fill(char, filter_itr *, simple_buffer *)' repl-t.hh:54: instantiated from `repl_itr,-1,-1>::value()' map_repl.hh:46: instantiated from here map_repl-t.hh:47: `const basic_rcon::pair *' is not a class, struct, or union type map_repl-t.hh:48: `const basic_rcon::pair *' is not a class, struct, or union type suppose to mean? TWO Has any one considered an option to produce better formatted error messages. For example: map_repl-t.hh:75: conversion from `find_substr_return,const basic_rcon::pair *>' to non-scalar type `find_substr_return,basic_rcon::pair *>' requested would be a LOT more readable as: map_repl-t.hh:75: conversion from: find_substr_return, const basic_rcon::pair *> to non-scalar type: find_substr_return, basic_rcon::pair *> requested. -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-8958-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 07:25:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12100 invoked by alias); 10 Aug 1999 07:25:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12078 invoked from network); 10 Aug 1999 07:25:04 -0000 Received: from ns3.eds.com (HELO spmler1.mail.eds.com) (194.128.225.190) by egcs.cygnus.com with SMTP; 10 Aug 1999 07:25:04 -0000 Received: from nnse.eds.com (nnse.eds.com [205.191.69.78]) by spmler1.mail.eds.com (8.9.3/8.9.3) with ESMTP id IAA02435 for ; Tue, 10 Aug 1999 08:26:29 +0100 (BST) Received: from gbspm010.exgb01.exch.eds.com (localhost [127.0.0.1]) by nnse.eds.com (8.9.3/8.9.3) with ESMTP id IAA18018 for ; Tue, 10 Aug 1999 08:20:58 +0100 (BST) Received: by GBSPM010 with Internet Mail Service (5.5.2448.0) id ; Tue, 10 Aug 1999 08:20:53 +0100 Message-ID: From: "Smithers, Kit" To: gcc@gcc.gnu.org Subject: keywords for operators (eg: and for &&) etc Date: Tue, 10 Aug 1999 08:20:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" I'm getting a little confused about the ability to use keywords such as "and" for "&&" and so on. g++ lets me use it in c++ code if I turn on -ansi which is listed as a C option. Yet ciso646 defines these keywords using macros only if __cplusplus is not set. Ideally I would like to enable the keywords in C++ but I may wish to use features which cause problems with -ansi (long long has recently been mentioned as problematic). Can anyone tell me what my mistake is ? thanks -- Kit Smithers From gcc-return-8959-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 07:32:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13092 invoked by alias); 10 Aug 1999 07:32:01 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13072 invoked from network); 10 Aug 1999 07:31:58 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 10 Aug 1999 07:31:58 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id BAA04186; Tue, 10 Aug 1999 01:29:41 -0600 X-Mailer: exmh version 2.0.2 To: Mark Klein cc: gcc@gcc.gnu.org Subject: Re: muldi3, divdi3 and remdi3 patterns Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 09 Aug 1999 07:52:12 PDT. <4.1.19990809074734.00cdecc0@garfield.dis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Aug 1999 01:29:41 -0600 Message-ID: <4183.934270181@upchuck.cygnus.com> From: Jeffrey A Law In message <4.1.19990809074734.00cdecc0@garfield.dis.com>you write: > So even though $$remoI is faster than the combination of $$mulo2I and Why would you even consider calling mul2I? Use 3 xmpyu instructions to do a standard cross-product multiply. Calling the mul2I routines is totally braindead. > I don't quite understand how the current costs have been allocated .. See RTX_COST, CONST_COSTS and friends. From gcc-return-8960-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 08:54:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19587 invoked by alias); 10 Aug 1999 08:54:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19572 invoked from network); 10 Aug 1999 08:54:20 -0000 Received: from unknown (HELO dsto.dp.ua) (195.24.142.29) by egcs.cygnus.com with SMTP; 10 Aug 1999 08:54:20 -0000 Received: from dsto.dp.ua [192.0.2.10] by dsto.dp.ua [195.24.142.29] with SMTP (MDaemon.v2.7.SP5.R) for ; Tue, 10 Aug 1999 11:27:37 +0200 Message-ID: <35CEACAE.97645595@dsto.dp.ua> Date: Mon, 10 Aug 1998 11:17:50 +0300 From: Nikonenko Konstantin Organization: Spectechattachment X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: About gcc under IRIX6.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: gcc@gcc.gnu.org X-Return-Path: kostya@dsto.dp.ua Reply-To: kostya@dsto.dp.ua Hi! I have a some problems with installation GCC i install GNU gcc 2.6.3 (version number 1022867720) and GNU binutils (version number 1022589620) under IRIX 6.3 SGI R5000 mips and have next message: ld: FATAL 9: I/O error (crt1.o): No such file or directory I find in documentation, that this error - if in system i haven't dev.sw.lib I don't know where i can find them, and if i must by it - where freeware? Sorry, but i can't open http://reality.sgi.com/ariel/freeware/ and in this case i send this message for You Best regards, Kostya Ukraine From gcc-return-8961-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 12:41:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21958 invoked by alias); 10 Aug 1999 12:41:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21925 invoked from network); 10 Aug 1999 12:41:06 -0000 Received: from chmls06.mediaone.net (24.128.1.71) by egcs.cygnus.com with SMTP; 10 Aug 1999 12:41:06 -0000 Received: from moshier.ne.mediaone.net (moshier.ne.mediaone.net [24.218.56.120]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id IAA22436 for ; Tue, 10 Aug 1999 08:40:54 -0400 (EDT) Date: Tue, 10 Aug 1999 08:40:54 -0400 (EDT) From: Stephen L Moshier X-Sender: moshier@moshier.ne.mediaone.net Reply-To: moshier@mediaone.net To: gcc@gcc.gnu.org Subject: How to not fold constants? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII IEEE awareness rules in C9X require that floating point constant expressions sometimes get folded and sometimes not. For example, if the expression occurs in executable code, it might not be folded; but if it is a static initializer it would be folded. It looks like c-parse.c makes up a tree containing the constant expression and passes that tree to fold-const.c, without any indication of the context where the expression came from in the source program. Other functions also call fold-const.c and maybe they are not aware of the context either. The question is, how can fold-const.c figure out whether the expression is a static initializer or is executable code? From gcc-return-8962-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 15:32:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8140 invoked by alias); 10 Aug 1999 15:32:29 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8120 invoked from network); 10 Aug 1999 15:32:18 -0000 Received: from metaip.checkpoint.com (HELO postal.metaip.checkpoint.com) (root@204.29.28.25) by egcs.cygnus.com with SMTP; 10 Aug 1999 15:32:18 -0000 Received: from cartman.metainfo.com (cartman.metainfo.com [204.29.28.145]) by postal.metaip.checkpoint.com (8.8.7/8.8.7) with ESMTP id IAA22646 for ; Tue, 10 Aug 1999 08:37:19 -0700 Received: from metaip.checkpoint.com (sneakers.metainfo.com [204.29.28.213]) by cartman.metainfo.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 3TJMYXS7; Tue, 10 Aug 1999 08:31:27 -0700 Message-ID: <37B04600.F4588F67@metaip.checkpoint.com> Date: Tue, 10 Aug 1999 08:32:16 -0700 From: Mark Atkinson Organization: Checkpoint Technologies MetaIP group X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: unmodified 2.95 build/install success (intel FreeBSD 3.2-RELEASE) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [config.guess output] i386-unknown-freebsdelf -- Mark Atkinson Checkpoint Technologies MetaIP Group !(wired)?(coffee++):(wired) From gcc-return-8963-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 15:58:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14689 invoked by alias); 10 Aug 1999 15:58:12 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14649 invoked from network); 10 Aug 1999 15:58:07 -0000 Received: from garfield.dis.com (199.4.97.30) by egcs.cygnus.com with SMTP; 10 Aug 1999 15:58:07 -0000 Received: from linus (198.180.205.14) by garfield.dis.com (EMWAC SMTPRS 0.81) with SMTP id ; Tue, 10 Aug 1999 08:58:05 -0700 Message-Id: <4.1.19990810085233.00c17300@garfield.dis.com> X-Sender: mark@garfield.dis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 10 Aug 1999 08:58:03 -0700 To: law@cygnus.com From: Mark Klein Subject: Re: muldi3, divdi3 and remdi3 patterns Cc: gcc@gcc.gnu.org In-Reply-To: <4183.934270181@upchuck.cygnus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 01:29 AM 8/10/99 -0600, Jeffrey A Law wrote: > > In message <4.1.19990809074734.00cdecc0@garfield.dis.com>you write: > > So even though $$remoI is faster than the combination of $$mulo2I and >Why would you even consider calling mul2I? Use 3 xmpyu instructions to do a >standard cross-product multiply. Calling the mul2I routines is totally >braindead. PA 1.0 is the primary reason - many of the HP3000's are still PA 1.0 boxes without xmpyu. Regardless, it's the $$rem.. millicode that I'm trying to add. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available -- From gcc-return-8964-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 15:59:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15206 invoked by alias); 10 Aug 1999 15:59:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15187 invoked from network); 10 Aug 1999 15:59:16 -0000 Received: from jeffco.k12.co.us (204.98.1.1) by egcs.cygnus.com with SMTP; 10 Aug 1999 15:59:16 -0000 Received: from jeffco.k12.co.us ([204.98.153.4]) by jeffco.k12.co.us (8.8.7/8.8.7) with ESMTP id JAA28040 for ; Tue, 10 Aug 1999 09:58:55 -0600 (MDT) Message-ID: <37B04BBC.253DE86B@jeffco.k12.co.us> Date: Tue, 10 Aug 1999 09:56:44 -0600 From: Dan Durden X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: hpux 10.20 gcc binaries? Content-Type: multipart/mixed; boundary="------------35C535E57FC724F536060863" This is a multi-part message in MIME format. --------------35C535E57FC724F536060863 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am searching for pre-compiled gcc (2.7.2.2 or later) because my hp box does not have a compiler already on it. Thanks, Dan Durden --------------35C535E57FC724F536060863 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Durden Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Daniel Durden n: Durden;Daniel org: Jefferson County Schools, Networking Services email;internet: ddurden@jeffco.k12.co.us title: System Administrator x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------35C535E57FC724F536060863-- From gcc-return-8965-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 16:14:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18089 invoked by alias); 10 Aug 1999 16:14:23 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18071 invoked from network); 10 Aug 1999 16:14:22 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 10 Aug 1999 16:14:22 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id JAA24003; Tue, 10 Aug 1999 09:13:22 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id JAA15660; Tue, 10 Aug 1999 09:13:21 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id JAA06715; Tue, 10 Aug 1999 09:13:21 -0700 Message-Id: <199908101613.JAA06715@atrus.synopsys.com> Subject: Re: keywords for operators (eg: and for &&) etc To: kit.smithers@eds.com (Smithers, Kit) Date: Tue, 10 Aug 99 9:13:21 PDT Cc: gcc@gcc.gnu.org In-Reply-To: ; from "Smithers, Kit" at Aug 10, 99 8:20 am X-Mailer: ELM [version 2.3 PL11] > I'm getting a little confused about the ability to use keywords such as > "and" for "&&" and so on. It's not the default because there are a number of platforms where these keywords appear in headers, and not all of them are cleaned up. > g++ lets me use it in c++ code if I turn on -ansi which is listed as a C > option. Yet ciso646 defines these keywords using macros only if __cplusplus > is not set. No, -ansi is both a C and a C++ option; basically it means "comply more closely with standards". It has the effect of turning off certain GNU extensions, and turning on features that may conflict with backward compatibility. (Thanks for pointing out a bug in the manual, which describes -ansi as only a C option). > Ideally I would like to enable the keywords in C++ but I may wish to use > features which cause problems with -ansi (long long has recently been > mentioned as problematic). Can anyone tell me what my mistake is ? -ansi will not reject programs that use extensions if those programs can't be valid ANSI (ISO) C or C++, so it accepts "long long". The -pedantic flag will reject "long long". But you can use the flag -foperator-names to turn on the operator names but not change anything else. From gcc-return-8966-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 16:20:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19910 invoked by alias); 10 Aug 1999 16:19:54 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19818 invoked from network); 10 Aug 1999 16:19:45 -0000 Received: from mail.pentek.com (HELO wiggum.pentek.com) (root@207.207.207.50) by egcs.cygnus.com with SMTP; 10 Aug 1999 16:19:45 -0000 Received: from pentek.com (charles-pc.pentek.com [192.168.200.52]) by wiggum.pentek.com (8.9.3/8.9.3) with ESMTP id MAA26827 for ; Tue, 10 Aug 1999 12:19:42 -0400 Message-ID: <37B05187.5C97E443@pentek.com> Date: Tue, 10 Aug 1999 12:21:27 -0400 From: Charles Krug Organization: Pentek Corporation X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Building cross, gcc reports error I don't see. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello List: I'm building gcc on sparc-solaris for m68k-wrs-vxworks targets. I get the error: m68k-wrs-vxworks/sys-include/sys/stat.h:43 parse error before ULONG I don't see any error here. Here's the section of stat.h in question. I've pasted the whole preamble after this in case anyone's a glutton for punishment or if there's something in that bit I've missed. What incredibly obvious thing have I overlooked here? Thanx Charles ------------------------------------------------------------------------- (opening bits of stat.h snipped) struct stat { ->> ULONG st_dev; /* device ID number */ <<- Line 43 ULONG st_ino; /* file serial number */ USHORT st_mode; /* file mode (see below) */ short st_nlink; /* number of links to file */ short st_uid; /* user ID of file's owner */ short st_gid; /* group ID of file's group */ ULONG st_rdev; /* device ID, only if special file */ ULONG st_size; /* size of file, in bytes */ TIME st_atime; /* time of last access */ TIME st_mtime; /* time of last modification */ TIME st_ctime; /* time of last change of file status */ long st_blksize; long st_blocks; UINT8 st_attrib; /* file attribute byte (dosFs only) */ int reserved1; /* reserved for future use */ int reserved2; /* reserved for future use */ int reserved3; /* reserved for future use */ int reserved4; /* reserved for future use */ int reserved5; /* reserved for future use */ int reserved6; /* reserved for future use */ }; Here's the whole preamble, in case I've overlooked something. ----------------------------------------------------------------------------------- /* stat.h - POSIX definitions for obtaining file characteristics */ /* Copyright 1984-1995 Wind River Systems, Inc. */ /* modification history -------------------- 01l,28mar95,kdl removed obsolete date/time fields from stat structure. 01k,19apr94,jmm added support for file system stat ({f}statfs()) 01j,22sep92,rrr added support for c++ 01i,18sep92,smb added mkdir prototype 01h,26may92,rrr the tree shuffle 01g,04oct91,rrr passed through the ansification filter -fixed #else and #endif -changed TINY and UTINY to INT8 and UINT8 -changed copyright notice 01f,10jun91.del added pragma for gnu960 alignment. 01e,05oct90,dnw added fstat() and stat() declarations. 01d,05oct90,shl added copyright notice. made #endif ANSI style. 01c,03oct90,kdl changed comments. 01b,05may90,llk added st_blksize and st_blocks fields so that net directory can use stat structure. Coincided with removal of h/net/stat.h. 01a,30apr90,kdl written. */ #ifndef __INCstath #define __INCstath #ifdef __cplusplus extern "C" { #endif #if ((CPU_FAMILY==I960) && (defined __GNUC__)) #pragma align 1 /* tell gcc960 not to optimize alignments */ #endif /* CPU_FAMILY==I960 */ #define TIME unsigned long /* type for file time fields */ struct stat { ULONG st_dev; /* device ID number */ ULONG st_ino; /* file serial number */ USHORT st_mode; /* file mode (see below) */ short st_nlink; /* number of links to file */ short st_uid; /* user ID of file's owner */ short st_gid; /* group ID of file's group */ ULONG st_rdev; /* device ID, only if special file */ ULONG st_size; /* size of file, in bytes */ TIME st_atime; /* time of last access */ TIME st_mtime; /* time of last modification */ TIME st_ctime; /* time of last change of file status */ long st_blksize; long st_blocks; UINT8 st_attrib; /* file attribute byte (dosFs only) */ int reserved1; /* reserved for future use */ int reserved2; /* reserved for future use */ int reserved3; /* reserved for future use */ int reserved4; /* reserved for future use */ int reserved5; /* reserved for future use */ int reserved6; /* reserved for future use */ }; -- Charles Krug, Jr. Application Engineer Pentek Corp 1 Park Way Upper Saddle River, NJ 07458 From gcc-return-8967-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 16:39:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24587 invoked by alias); 10 Aug 1999 16:39:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24503 invoked from network); 10 Aug 1999 16:38:40 -0000 Received: from gatekeep.ti.com (192.94.94.61) by egcs.cygnus.com with SMTP; 10 Aug 1999 16:38:40 -0000 Received: from tilde.csc.ti.com ([157.170.1.149]) by gatekeep.ti.com (8.9.3) with ESMTP id LAA13314; Tue, 10 Aug 1999 11:37:28 -0500 (CDT) Received: from tiuk.ti.com (fantastic.tiuk.ti.com [137.167.91.143]) by tilde.csc.ti.com (8.9.3/8.8.8) with ESMTP id LAA06919; Tue, 10 Aug 1999 11:37:26 -0500 (CDT) Received: from pluto.tiuk.ti.com by tiuk.ti.com (8.8.8+Sun/SMI-SVR4) id RAA05323; Tue, 10 Aug 1999 17:37:24 +0100 (BST) Date: Tue, 10 Aug 1999 17:37:24 +0100 (BST) Message-Id: <199908101637.RAA05323@tiuk.ti.com> Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: tkmail-0.011/Perl5 Mail::Internet v1.32 In-Reply-To: <37B05187.5C97E443@pentek.com> from Charles Krug on Tue, 10 Aug 1999 12:21:27 -0400 Subject: Re: Building cross, gcc reports error I don't see. From: Nick Ing-Simmons References: <37B05187.5C97E443@pentek.com> Organization: via, but not speaking for : Texas Instruments Ltd. To: charles@pentek.com Cc: gcc@gcc.gnu.org Reply-To: Nick Ing-Simmons Charles Krug writes: >Hello List: > >I'm building gcc on sparc-solaris for m68k-wrs-vxworks targets. > >I get the error: > >m68k-wrs-vxworks/sys-include/sys/stat.h:43 parse error before >ULONG Pretty normal for an undeclared type. > >I don't see any error here. Here's the section of stat.h in >question. I've pasted the whole preamble after this in case >anyone's a glutton for punishment or if there's something in that >bit I've missed. > >What incredibly obvious thing have I overlooked here? #including whichever .h file provides typedef or #define for ULONG _before_ including > >Thanx > > >Charles >------------------------------------------------------------------------- > >(opening bits of stat.h snipped) > >struct stat > { > >->> ULONG st_dev; /* device ID number */ <<- Line 43 > > -- Nick Ing-Simmons Via, but not speaking for: Texas Instruments Ltd. From gcc-return-8968-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 17:11:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30346 invoked by alias); 10 Aug 1999 17:11:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30331 invoked from network); 10 Aug 1999 17:11:54 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 10 Aug 1999 17:11:54 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id KAA22385; Tue, 10 Aug 1999 10:11:53 -0700 (PDT) Received: by kankakee.wrs.com (SMI-8.6/SMI-SVR4) id KAA01555; Tue, 10 Aug 1999 10:11:52 -0700 Date: Tue, 10 Aug 1999 10:11:52 -0700 From: mrs@wrs.com (Mike Stump) Message-Id: <199908101711.KAA01555@kankakee.wrs.com> To: charles@pentek.com, gcc@gcc.gnu.org Subject: Re: Building cross, gcc reports error I don't see. > Date: Tue, 10 Aug 1999 12:21:27 -0400 > From: Charles Krug > To: gcc@gcc.gnu.org > m68k-wrs-vxworks/sys-include/sys/stat.h:43 parse error before > ULONG > I don't see any error here. > What incredibly obvious thing have I overlooked here? gcc -E will show you the error. grep ULONG target/h/* will hopefully show you the missing header. From gcc-return-8969-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 17:44:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2043 invoked by alias); 10 Aug 1999 17:44:37 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2014 invoked from network); 10 Aug 1999 17:44:06 -0000 Received: from caip.rutgers.edu (128.6.236.10) by egcs.cygnus.com with SMTP; 10 Aug 1999 17:44:06 -0000 Received: (from ghazi@localhost) by caip.rutgers.edu (8.9.3/8.9.3) id NAA21180 for egcs@egcs.cygnus.com; Tue, 10 Aug 1999 13:43:55 -0400 (EDT) Date: Tue, 10 Aug 1999 13:43:55 -0400 (EDT) From: "Kaveh R. Ghazi" Message-Id: <199908101743.NAA21180@caip.rutgers.edu> To: egcs@egcs.cygnus.com Subject: What's the deal with MD_CALL_PROTOTYPES ? So I'm prototyping stuff in insn-* and I notice that the macro MD_CALL_PROTOTYPES wraps gen_call() and gen_call_value() in insn-flags.h. The docs says this: > `MD_CALL_PROTOTYPES' > Define this if you wish to generate prototypes for the `gen_call' > or `gen_call_value' functions generated from the machine > description file. If `USE_PROTOTYPES' is defined to be 0, or the > host compiler does not support prototypes, or `NO_MD_PROTOTYPES' > is defined, this macro has no effect. As soon as all of the > machine descriptions are modified to have the appropriate number > of arguments, this macro will be removed. So I was wondering can it be removed? Judging from the insn-flags.h vs insn-emit.c output, it looks like Irix6 gets it right, but not solaris2. How hard is it to fix this? Can we move ahead with nuking the macro? --Kaveh -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions From gcc-return-8970-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 18:13:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5111 invoked by alias); 10 Aug 1999 18:13:01 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5090 invoked from network); 10 Aug 1999 18:12:54 -0000 Received: from fireserv.molienergy.bc.ca (HELO mailserv.molienergy.bc.ca) (207.216.249.2) by egcs.cygnus.com with SMTP; 10 Aug 1999 18:12:54 -0000 Received: by mailserv.molienergy.bc.ca with Internet Mail Service (5.0.1458.49) id <366VH8N9>; Tue, 10 Aug 1999 11:09:47 -0700 Message-ID: <71B30885B657D111809D080009EEBBF39C9F3B@mailserv.molienergy.bc.ca> From: Jan Reimers To: 'Joe Buck' , "'colomon@ralf.org'" Cc: "'gcc@gcc.gnu.org'" Subject: RE: a barely useful option? Date: Tue, 10 Aug 1999 11:09:46 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain As another example. The idea of expression templates is critically dependant on having non-virtual base class destructors (that work). In this paradigm, multiple nested template classes are used to convert "array arithmetic" into suitable/tight loops. All the expression template classes are inline and completely optimized away at compile time. One virtual base class destructor would result in significant code bloat from all the v-tables. JR > ---------- > From: Joe Buck[SMTP:jbuck@synopsys.COM] > Sent: Monday, August 09, 1999 2:00 PM > To: colomon@ralf.org > Cc: gcc@gcc.gnu.org > Subject: Re: a barely useful option? > > > Joe Buck writes: > > > If the implementation were effortless, the warning could be put in > but > > > modified to behave as follows: OK, so the base class has a > non-virtual > > > destructor. Consider this code: > > > > > > Base* b = new Derived(constructor-args); > > > .... > > > delete b; > > > > > > will the right thing happen? Well, if Derived has no additional > data > > > members and does not declare a destructor, the right thing does > happen, so > > > the compiler should never issue a warning in such a case. > > Sol Foster writes: > > > My understanding is that doing this results in undefined behavior > > according to the standard. I can't cite the standard on this, alas, > but > > the C++ FAQ claims that a virtual destructor *is* required if the > base > > class destructor is non-trivial. > > You are correct that the standard reads that way. I challenge anyone > to name an existing C++ compiler in which the right thing does not > happen. > Given the fact that the GNU, Microsoft, KAI, HP, Sun, SGI, Borland, > etc > compilers all have this property, it is nonsensical to ask programmers > to make their code substantially worse in order to satisfy language > lawyers on this particular point. > > Possibly the -pedantic flag should issue the warning, since the > undefined > behavior is only theoretical. It certainly doesn't belong in -Wall. > > There was a similar issue on whether vector elements are guaranteed > contiguous or not, it ended up getting settled by a defect report. I > suspect that at least some of the committee would feel the same way on > this one: > > Given that: > 1. We have nonvirtual Base::~Base. > 2. We have a derived class with no additional members (single > nonvirtual > inheritance) that does not declare Derived::~Derived > 3. Someone writes code like the above (deletes a Derived object > through > a Base pointer) > > come up with an argument that the behavior is undefined is not > equivalent > to "that's what the standard says". For every existing compiler > Base::~Base will get called and the right thing will happen. > > I claim that such code is completely portable. If you disagree, you > need to show me a compiler *that someone might actually want to use* > in which something different happens. > > > It may work in GCC, but there are no guarantees in other compilers, > and > > so it is exactly the sort of thing one would like to be warned > about. > > No, people do not want to be told to make their code worse. I have > code > for which I expect a 3x performance penalty if I take the Effective > C++ > style recommendation here. > > > > > From gcc-return-8971-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 19:00:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9471 invoked by alias); 10 Aug 1999 19:00:35 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9455 invoked from network); 10 Aug 1999 19:00:32 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 10 Aug 1999 19:00:32 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id LAA11338; Tue, 10 Aug 1999 11:52:32 -0700 Message-Id: <199908101852.LAA11338@zack.bitmover.com> To: gcc@gcc.gnu.org, rth@cygnus.com Subject: 2.95, x86: severe performance problems with short arithmetic Date: Tue, 10 Aug 1999 11:52:32 -0700 From: Zack Weinberg This function unsigned short cksum(unsigned char *buf1, unsigned char *buf2) { unsigned short sum = 0; unsigned char *p, *q, c; p = buf1; q = buf2; for (;;) { c = *p++; if (c == '\0') break; sum += c; *q++ = c; if (c == '\n') break; } return (sum); } is approximately twice as slow when compiled by 2.95 as 2.7. The entire performance penalty can be blamed on one instruction, which I have starred below. This dump was generated by the current mainline, but 2.95 generates identical code. .file "fpd2.c" .version "01.01" gcc2_compiled.: .text .align 4 .globl cksum .type cksum,@function cksum: pushl %esi # 80 movsi-2 pushl %ebx # 81 movsi-2 movl 12(%esp),%ebx # 15 movsi+2/2 movl 16(%esp),%ecx # 18 movsi+2/2 xorl %esi,%esi # 12 movhi+1/1 .p2align 4,,7 .L3: movb (%ebx),%dl # 26 movqi+1/1 incl %ebx # 27 addsi3+1/1 testb %dl,%dl # 29 tstqi_1 je .L4 # 30 bleu+1 movzbw %dl,%ax # 35 zero_extendqihi2+1 *** addl %eax,%esi # 37 addhi3+1/1 movb %dl,(%ecx) # 41 movqi+1/3 incl %ecx # 42 addsi3+1/1 cmpb $10,%dl # 44 cmpqi_1/2 jne .L3 # 45 bleu+1 .L4: movzwl %si,%eax # 61 zero_extendhisi2+1 popl %ebx # 84 pop popl %esi # 85 pop ret # 86 return_internal .Lfe1: .size cksum,.Lfe1-cksum .ident "GCC: (GNU) 2.96 19990808 (experimental)" If I change that instruction to 'addw %ax,%si' the code is as fast as that produced by 2.7 (and indeed 2.7 uses an addw here). The new_ia32_branch uses an addw for this case, so the problem is fixed, but It Would Be Really Nice if it could get fixed in 2.95.1 as well. (I am attempting to convince my boss of the wisdom of dropping 2.7, and a 30% performance penalty for real code isn't helping me any...) The corresponding insn is in HImode all the way to the .stack dump: (insn 37 35 41 (set (reg/v:HI 4 %si) (plus:HI (reg/v:HI 4 %si) (reg:HI 0 %ax))) 208 {addhi3+1} (insn_list/j/c 35 (insn_list/j/c 35 (nil))) (expr_list:REG_DEAD (reg:HI 0 %ax) (nil))) so I am guessing that the problem is with this piece of i386.md: (define_insn "" [(set (match_operand:HI 0 "nonimmediate_operand" "=rm,r,?r") (plus:HI (match_operand:HI 1 "nonimmediate_operand" "%0,0,r") (match_operand:HI 2 "general_operand" "ri,rm,ri")))] "ix86_binary_operator_ok (PLUS, HImode, operands)" "* { /* ... */ /* Use a 32-bit operation when possible, to avoid the prefix penalty. */ if (REG_P (operands[0]) && i386_aligned_p (operands[2]) && i386_cc_probably_useless_p (insn)) { CC_STATUS_INIT; if (GET_CODE (operands[2]) == CONST_INT) { HOST_WIDE_INT intval = 0xffff & INTVAL (operands[2]); if (intval == 1) return AS1 (inc%L0,%k0); if (intval == 0xffff) return AS1 (dec%L0,%k0); operands[2] = i386_sext16_if_const (operands[2]); } return AS2 (add%L0,%k2,%k0); } if (operands[2] == const1_rtx) return AS1 (inc%W0,%0); if (operands[2] == constm1_rtx || (GET_CODE (operands[2]) == CONST_INT && INTVAL (operands[2]) == 65535)) return AS1 (dec%W0,%0); return AS2 (add%W0,%2,%0); }" [(set_attr "type" "binary")]) Looks like it would suffice to rip out the entire if block - but there was a reason it was put there in the first place, right? zw From gcc-return-8972-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 19:18:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12855 invoked by alias); 10 Aug 1999 19:18:52 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12836 invoked from network); 10 Aug 1999 19:18:45 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 10 Aug 1999 19:18:45 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id NAA05820; Tue, 10 Aug 1999 13:16:12 -0600 X-Mailer: exmh version 2.0.2 To: Zack Weinberg cc: gcc@gcc.gnu.org, rth@cygnus.com Subject: Re: 2.95, x86: severe performance problems with short arithmetic Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 10 Aug 1999 11:52:32 PDT. <199908101852.LAA11338@zack.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Aug 1999 13:16:12 -0600 Message-ID: <5817.934312572@upchuck.cygnus.com> From: Jeffrey A Law In message <199908101852.LAA11338@zack.bitmover.com>you write: > so I am guessing that the problem is with this piece of i386.md: Yes. Read the comments and the changelog. That'll tell you why it is there and who put it in. Iterate with them over the change. We do not want to just rip out that block. That is not a solution. jeff From gcc-return-8973-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 19:36:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15237 invoked by alias); 10 Aug 1999 19:36:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15222 invoked from network); 10 Aug 1999 19:36:46 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 10 Aug 1999 19:36:45 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id MAA12017; Tue, 10 Aug 1999 12:28:57 -0700 Message-Id: <199908101928.MAA12017@zack.bitmover.com> To: law@cygnus.com cc: gcc@gcc.gnu.org, rth@cygnus.com Subject: Re: 2.95, x86: severe performance problems with short arithmetic In-Reply-To: Message from Jeffrey A Law of "Tue, 10 Aug 1999 13:16:12 MDT." <5817.934312572@upchuck.cygnus.com> Date: Tue, 10 Aug 1999 12:28:57 -0700 From: Zack Weinberg Jeffrey A Law wrote: > In message <199908101852.LAA11338@zack.bitmover.com>you write: > > so I am guessing that the problem is with this piece of i386.md: > Yes. Read the comments and the changelog. That'll tell you why it is > there and who put it in. Iterate with them over the change. > > We do not want to just rip out that block. That is not a solution. The block in question has been there since before the 1.1 rev of i386.md. I don't see anything that looks related in any of the FSFChangeLog files available to me. zw From gcc-return-8974-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 19:40:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15782 invoked by alias); 10 Aug 1999 19:40:12 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15710 invoked from network); 10 Aug 1999 19:39:45 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 10 Aug 1999 19:39:45 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id VAA01187; Tue, 10 Aug 1999 21:38:39 +0200 Message-ID: <37B07FBF.75C0076C@moene.indiv.nluug.nl> Date: Tue, 10 Aug 1999 21:38:39 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: moshier@mediaone.net CC: gcc@gcc.gnu.org Subject: Re: How to not fold constants? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen L Moshier wrote: > IEEE awareness rules in C9X require that floating point constant > expressions sometimes get folded and sometimes not. For example, if > the expression occurs in executable code, it might not be folded; but ^^^^^ ^^^ "might not" or "shall not" ? > if it is a static initializer it would be folded. ^^^^^ "would" or "shall" ? > It looks like c-parse.c makes up a tree containing the constant > expression and passes that tree to fold-const.c, without any indication > of the context where the expression came from in the source program. > Other functions also call fold-const.c and maybe they are not aware > of the context either. The question is, how can fold-const.c figure > out whether the expression is a static initializer or is executable code? I think an easier (and more obvious IMHO) solution is to have the C frontend "Do The Right Thing", i.e. call build(fold(...)) in case of a static initializer and build(...) otherwise [or is there a snag in there that I'm overlooking ?] More serious is the problem of constant propagation. I do not know off-hand how much cprop gcc does these days, but with it, the following code: p = 0.1; ... /* no intervening assignments to p */ for (i = 0; i < n; i++) a[i] = 10.0 * p * b[i]; could be turned into: for (i = 0; i < n; i++) a[i] = one * b[i]; where `one' is the constant one gets when letting the compiler combine 0.1 * 10.0 instead of letting it happen at run time ["what's the difference ?" I hear from the audience. The difference is that the rounding mode (away from or towards zero or up or down) might be different at compile time than at run time, giving you a different `one']. It's not clear from your mail what the C9X standard requires here, but for consistency's sake I would say that it also has to prohibit this "constant folding". -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-8975-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 19:44:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16383 invoked by alias); 10 Aug 1999 19:44:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16324 invoked from network); 10 Aug 1999 19:44:16 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 10 Aug 1999 19:44:16 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id PAA14502; Tue, 10 Aug 1999 15:43:54 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id PAA01276; Tue, 10 Aug 1999 15:43:53 -0400 (EDT) Date: Tue, 10 Aug 1999 15:43:53 -0400 (EDT) From: John Wehle Message-Id: <199908101943.PAA01276@jwlab.FEITH.COM> To: zack@bitmover.com Subject: Re: 2.95, x86: severe performance problems with short arithmetic Cc: gcc@gcc.gnu.org Content-Type: text > Looks like it would suffice to rip out the entire if block - but there > was a reason it was put there in the first place, right? ix86 word instructions generally require a prefix which makes the resulting instruction larger and complicates decoding. ix86 word instructions also can cause partial register stalls on P6 class processors (as you have apparentally noticed :-). The various ix86 patterns in i386.md attempt to avoid word instructions when possible so to hopefully produce better code, however at times they just make the situation worse. Consider the following: 1) A 16 bit write to a register immediately followed by a 32 bit read of the register. This will cause a stall. Converting the 16 bit write to a 32 bit write avoids the stall, however this may cause a stall with an earlier instruction (if I recall correctly). 2) A 16 bit write to a register followed by several other instructions which don't reference the register followed by a 32 bit read of the register. This will not stall. Really the code needs to do more analysis and scheduling to properly handle the issue of avoiding the prefix and partial register stalls. Any takers? :-) -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-8976-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 20:08:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19558 invoked by alias); 10 Aug 1999 20:08:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19536 invoked from network); 10 Aug 1999 20:08:15 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 10 Aug 1999 20:08:15 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id WAA28334; Tue, 10 Aug 1999 22:02:16 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id VAA00698; Tue, 10 Aug 1999 21:58:44 +0200 Date: Tue, 10 Aug 1999 21:58:44 +0200 Message-Id: <199908101958.VAA00698@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: kevinatk@home.com CC: gcc@gcc.gnu.org In-reply-to: <37AFD2B7.15891BA0@home.com> (message from Kevin Atkinson on Tue, 10 Aug 1999 03:20:23 -0400) Subject: Re: C++ Error message question and suggestion. References: <37AFD2B7.15891BA0@home.com> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > What does "`const basic_rcon::pair *' is not a class, struct, or union > type" as given by: [...] > suppose to mean? Exactly that: const basic_rcon::pair * is a "pointer type", and neither a struct, nor a class, nor a union. And - it should be, in the place where you use it - which is a qualification in a template instantiation, such as template struct S{ typename T::foo::bar x; }; struct A{ typedef int foo; }; S X; Here, template S assumes that T::foo is a class, struct, or union type which has a nested type "bar" - however, T::foo is `int', hence the error. > Has any one considered an option to produce better formatted error > messages. Not to my knowledge, no. There have been numerous proposals for improving the error messages, but none that deals with reformatting them to be more readable. If you can find an algorithm that makes it more readable, a patch to the compiler would be most welcome. Regards, Martin From gcc-return-8977-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 20:18:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22747 invoked by alias); 10 Aug 1999 20:18:23 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22732 invoked from network); 10 Aug 1999 20:18:17 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 10 Aug 1999 20:18:17 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id NAA16248; Tue, 10 Aug 1999 13:10:23 -0700 Message-Id: <199908102010.NAA16248@zack.bitmover.com> To: John Wehle cc: gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic In-Reply-To: Message from John Wehle of "Tue, 10 Aug 1999 15:43:53 EDT." <199908101943.PAA01276@jwlab.FEITH.COM> Date: Tue, 10 Aug 1999 13:10:23 -0700 From: Zack Weinberg John Wehle wrote: > > Looks like it would suffice to rip out the entire if block - but there > > was a reason it was put there in the first place, right? > > ix86 word instructions generally require a prefix which makes the > resulting instruction larger and complicates decoding. ix86 word > instructions also can cause partial register stalls on P6 class > processors (as you have apparentally noticed :-). The various > ix86 patterns in i386.md attempt to avoid word instructions > when possible so to hopefully produce better code, however at > times they just make the situation worse. Consider the following: > > 1) A 16 bit write to a register immediately followed by a 32 bit read > of the register. This will cause a stall. Converting the 16 bit > write to a 32 bit write avoids the stall, however this may cause a > stall with an earlier instruction (if I recall correctly). Does this include something like this? movzbw %dl, %ax addl %eax, %esi It certainly sounds like it, and would explain why such a tiny difference turns into a 2x performance loss. ... > Really the code needs to do more analysis and scheduling to properly handle > the issue of avoiding the prefix and partial register stalls. > Any takers? :-) It appears to have already been done, in the new_ia32_branch. I was hoping for a quick fix that could go into 2.95.1, but I can wait for 2.96 or 3.0 or whatever. zw From gcc-return-8978-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 20:39:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25517 invoked by alias); 10 Aug 1999 20:38:53 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25395 invoked from network); 10 Aug 1999 20:38:25 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 10 Aug 1999 20:38:25 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id QAA15084; Tue, 10 Aug 1999 16:38:10 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id QAA01478; Tue, 10 Aug 1999 16:38:09 -0400 (EDT) Date: Tue, 10 Aug 1999 16:38:09 -0400 (EDT) From: John Wehle Message-Id: <199908102038.QAA01478@jwlab.FEITH.COM> To: zack@bitmover.com Cc: gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Content-Type: text >> 1) A 16 bit write to a register immediately followed by a 32 bit read >> of the register. This will cause a stall. Converting the 16 bit >> write to a 32 bit write avoids the stall, however this may cause a >> stall with an earlier instruction (if I recall correctly). > >Does this include something like this? > > movzbw %dl, %ax > addl %eax, %esi > Probably ... I don't have the relevant Intel document handy at the moment. There are certain special cases (if I recall). More information is available in the Intel Optimization Manual which should be available from http://developer.intel.com. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-8979-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 20:45:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26348 invoked by alias); 10 Aug 1999 20:45:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26282 invoked from network); 10 Aug 1999 20:44:43 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 10 Aug 1999 20:44:43 -0000 Received: (qmail 11039 invoked by alias); 10 Aug 1999 20:44:31 -0000 Received: (qmail 11030 invoked from network); 10 Aug 1999 20:44:30 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 10 Aug 1999 20:44:30 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id VAA21355; Tue, 10 Aug 1999 21:43:30 +0100 From: Joern Rennecke Message-Id: <199908102043.VAA21355@phal.cygnus.co.uk> Subject: Re: How to not fold constants? In-Reply-To: <37B07FBF.75C0076C@moene.indiv.nluug.nl> from Toon Moene at "Aug 10, 1999 9:38:39 pm" To: toon@moene.indiv.nluug.nl (Toon Moene) Date: Tue, 10 Aug 1999 21:43:30 +0100 (BST) Cc: moshier@mediaone.net, gcc@gcc.gnu.org X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I think an easier (and more obvious IMHO) solution is to have the C > frontend "Do The Right Thing", i.e. call build(fold(...)) in case of a > static initializer and build(...) otherwise [or is there a snag in there > that I'm overlooking ?] Yes. There might be integer expressions inside that we want to fold. We also want to fold floating point if this can be done without an inexact operation or generating NaNs. From gcc-return-8980-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 21:27:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31325 invoked by alias); 10 Aug 1999 21:27:40 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31289 invoked from network); 10 Aug 1999 21:27:37 -0000 Received: from gwdu42.gwdg.de (HELO gwdu12.gwdg.de) (134.76.10.26) by egcs.cygnus.com with SMTP; 10 Aug 1999 21:27:37 -0000 Received: from ras23-160.gwdg.de ([134.76.23.160]) by gwdu12.gwdg.de with smtp (Exim 2.12 #1) id 11EJQN-0003Dq-00; Tue, 10 Aug 1999 23:27:11 +0200 From: kthomas@gwdg.de (Philipp Thomas) To: "Kaveh R. Ghazi" Cc: gcc@gcc.gnu.org Subject: Re: What's the deal with MD_CALL_PROTOTYPES ? Date: Tue, 10 Aug 1999 21:27:05 GMT Message-ID: <37cf97ae.428180827@mailer.gwdg.de> References: <199908101743.NAA21180@caip.rutgers.edu> In-Reply-To: <199908101743.NAA21180@caip.rutgers.edu> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Tue, 10 Aug 1999 13:43:55 -0400 (EDT), "Kaveh R. Ghazi" wrote: > So I'm prototyping stuff in insn-* and I notice that the macro >MD_CALL_PROTOTYPES wraps gen_call() and gen_call_value() in >insn-flags.h. The docs says this: So you're stumbling over the same blocks that I did last time I tried to = do that :-/ >it looks like Irix6 gets it right, but not solaris2. Last I tried it, ia32 failed also. But when I asked for an explanation, nobody replied and on myself I failed to understand the mechanism behind the gen_call machinery. If you succeed in cleaning up all the md's, I'll certainly applaud ;-) Philipp --=20 Nothing would please me more than being able to hire ten programmers and deluge the hobby market with good software. -- Bill Gates, 1976 From gcc-return-8981-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 21:30:40 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32324 invoked by alias); 10 Aug 1999 21:30:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32237 invoked from network); 10 Aug 1999 21:30:25 -0000 Received: from www.4j.lane.edu (HELO vizard.4j.lane.edu) (158.165.5.25) by egcs.cygnus.com with SMTP; 10 Aug 1999 21:30:24 -0000 Received: (from johnm@localhost) by vizard.4j.lane.edu (8.9.3/8.9.0) id OAA06568; Tue, 10 Aug 1999 14:30:22 -0700 (PDT) Message-ID: <19990810143022.49636@vizard.4j.lane.edu> Date: Tue, 10 Aug 1999 14:30:22 -0700 From: John-Mark Gurney To: gcc@gcc.gnu.org Subject: GCC 2.95 on Solaris and shared objects... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Eugene 4J School District X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there I am trying to get a shared object to build under GCC 2.95 on Solaris 2.7 for Sparc, but text strings in a static structure are not being relocated... I had the same problem under egcs 1.1.2... basicly when I compile the module (showing one .c file and the linking): gcc -fPIC -DLDAP_REFERRALS -I/nfs_tools/src/ldap/include -g -O2 -pipe -I/nfs_tools/install/Python-1.5.2/include/python1.5 -I/nfs_tools/install/Python-1.5.2/include/python1.5 -DHAVE_CONFIG_H -c ./functions.c gcc -shared LDAPObject.o common.o constants.o errors.o functions.o ldapmodule.o message.o version.o -L/nfs_tools/src/ldap/libraries -lldap -llber -lsocket -lnsl -o ldapmodule.so in functions.c, it has a structure of: static PyMethodDef methods[] = { { "open", (PyCFunction)l_ldap_open, METH_VARARGS, doc_open }, { "dn2ufn", (PyCFunction)l_ldap_dn2ufn, METH_VARARGS, doc_dn2ufn }, { "explode_dn", (PyCFunction)l_ldap_explode_dn, METH_VARARGS, doc_explode_dn }, { "is_ldap_url", (PyCFunction)l_ldap_is_ldap_url, METH_VARARGS, doc_is_ldap_url }, { NULL, NULL } }; now when the module gets loaded, none of the pointers in this structure get relocated: (gdb) frame 3 #3 0xff149a0c in LDAPadd_methods (d=0xd4918, methods=0xff16eaf8) at ./common.c:18 18 PyDict_SetItemString( d, meth->ml_name, f ); (gdb) print *methods $1 = {ml_name = 0x158e68
, ml_meth = 0x14b5a8, ml_flags = 1, ml_doc = 0x16e770
} as you can see, the methods structure is actually located at 0xff16eaf8, and considering that the ml_name and friends are part of the same file, they shouldn't be at such a low address.... the above gdb was obtains from a core dump when trying to load the module.. if you haven't recognized this already, it's comiling a module for python that can be loading/imported at run time, but because of this problem, I haven't been able to get this to work... does anybody have any idea on how to fix this problem?? it seems strange that it would relocate some of the symbols but not all of them, considering that everything is compiled for pic... any help would be greatly apreciated... -- John-Mark Gurney Eugene 4J School District From gcc-return-8982-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 22:25:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6940 invoked by alias); 10 Aug 1999 22:25:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6847 invoked from network); 10 Aug 1999 22:24:37 -0000 Received: from jl1.quim.ucm.es (root@147.96.5.12) by egcs.cygnus.com with SMTP; 10 Aug 1999 22:24:37 -0000 Received: (from ramon@localhost) by jl1.quim.ucm.es (8.9.3/8.9.3) id AAA21980 for gcc@gcc.gnu.org; Wed, 11 Aug 1999 00:27:14 +0200 Date: Wed, 11 Aug 1999 00:27:14 +0200 From: "Ram'on Garc'ia Fern'andez" To: gcc@gcc.gnu.org Subject: Trying to enable access enforcement on typedefs. Message-ID: <19990811002714.A21972@jl1.quim.ucm.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us I have been looking at the GCC source code in order to contribute access enforcement for typedefs. But to my surprise, it appears to be intentionally disabled. gcc/cp/decl.c(line 5881): the function lookup_name_real contains a call to the function lookup_member, with the third parameter, protected = 0: val = lookup_member (type, name, 0, prefer_type); gcc/cp/search.c(line 992): the function access_p refuses to perform access checking for types, and a comment says that it has not been implemented: /* We don't do access control for types yet. */ if (TREE_CODE (decl) == TYPE_DECL) return 1; However, I enabled access check to types from gdb, using set protected = 1 for the first place and a jump command for the second. cc1plus did the access check correctly and my code did not compile as expected. I suppose that that there are some (probably subtle) problems in the implementation, and so GCC developers have choosen that it is better to allow incorrect code than something worse, such as generating incorrect code or giving an error for a correct program. Which are there problems? Ramon From gcc-return-8983-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 22:33:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9450 invoked by alias); 10 Aug 1999 22:32:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9396 invoked from network); 10 Aug 1999 22:32:36 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 10 Aug 1999 22:32:36 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id AAA08574; Wed, 11 Aug 1999 00:31:35 +0200 Message-ID: <37B0A847.B4EC8D0A@moene.indiv.nluug.nl> Date: Wed, 11 Aug 1999 00:31:35 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: Joern Rennecke CC: moshier@mediaone.net, gcc@gcc.gnu.org Subject: Re: How to not fold constants? References: <199908102043.VAA21355@phal.cygnus.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joern Rennecke wrote: > > I think an easier (and more obvious IMHO) solution is to have the C > > frontend "Do The Right Thing", i.e. call build(fold(...)) in case of a > > static initializer and build(...) otherwise [or is there a snag in there > > that I'm overlooking ?] > Yes. There might be integer expressions inside that we want to fold. Is that true - shouldn't the *frontend* decide how to interpret mixed mode expressions ? Or is fold-const.c so tied up with C that the Fortran frontend probably shouldn't use it ?!? > We also want to fold floating point if this can be done without an > inexact operation or generating NaNs. The challenge is to determine that the outcome after folding has a single correct result, independent of the rounding mode (round to nearest, round to zero, round up or round down - note, I got the first one wrong in my original message) applied to the constituent numerical operations. This condition is necessary, because the compiler cannot know what the rounding mode _is_, at run time [Off-hand, I'd think that trying to determine this is equivalent to the halting problem]. Seems like quite a challenge - I wouldn't be surprised if there weren't _that_ many expressions for which this holds. -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html PS: wish you a sunny eclipse :-) From gcc-return-8984-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 22:40:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12510 invoked by alias); 10 Aug 1999 22:40:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12461 invoked from network); 10 Aug 1999 22:39:55 -0000 Received: from hebe.or.intel.com (134.134.248.4) by egcs.cygnus.com with SMTP; 10 Aug 1999 22:39:55 -0000 Received: from ichips-ra.pdx.intel.com (ichips-ra.pdx.intel.com [137.102.192.31]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id PAA25292 for ; Tue, 10 Aug 1999 15:50:29 -0700 (PDT) Received: from pdxnw392 (pdxnw392.pdx.intel.com [137.102.203.90]) by ichips-ra.pdx.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with SMTP id PAA19569 for ; Tue, 10 Aug 1999 15:39:53 -0700 (PDT) From: "Gordon Neal" To: Subject: build of glibc-2.1.1 using gcc-2.9.5 Date: Tue, 10 Aug 1999 15:39:53 -0700 Message-ID: <003a01bee381$437d3d00$5acb6689@pdxnw392.pdx.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Greetings, I can't build/configure glibc-2.1.1 using gcc-2.9.5. I get the following messages: checking host system type... i686-pc-linux-gnu checking sysdep dirs... sysdeps/i386/elf linuxthreads/sysdeps/unix/sysv/linux linuxthreads/sysdeps/pthread linuxthreads/sysdeps/unix/sysv linuxthreads/sysdeps/unix linuxthreads/sysdeps/i386/i686 linuxthreads/sysdeps/i386 crypt/sysdeps/unix sysdeps/unix/sysv/linux/i386/i686 sysdeps/unix/sysv/linux/i386 sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman sysdeps/unix/inet sysdeps/unix/sysv/i386 sysdeps/unix/sysv sysdeps/unix/i386 sysdeps/unix sysdeps/posix sysdeps/i386/i686 sysdeps/i386/i486 sysdeps/libm-i387/i686 sysdeps/i386/fpu sysdeps/libm-i387 sysdeps/i386 sysdeps/wordsize-32 sysdeps/ieee754 sysdeps/libm-ieee754 sysdeps/generic/elf sysdeps/generic checking for a BSD compatible install... /usr/bin/install -c checking whether ln -s works... yes checking build system type... i686-pc-linux-gnu checking for gcc... gcc checking version of gcc... 2.95, bad checking for make... make checking version of make... 3.77, ok checking for msgfmt... msgfmt checking version of msgfmt... 0.10.35, ok checking for makeinfo... makeinfo checking version of makeinfo... 3.12, ok configure: error: *** Some critical program is missing or too old. *** Check the INSTALL file for required versions. Is there a work-around for this or do I have to use an older version of gcc? Thanks Gordon The pioneers get the arrows ... The settlers get the corn. From gcc-return-8985-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 22:50:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16007 invoked by alias); 10 Aug 1999 22:50:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15989 invoked from network); 10 Aug 1999 22:50:15 -0000 Received: from nexus.carleton.ca (root@134.117.76.10) by egcs.cygnus.com with SMTP; 10 Aug 1999 22:50:15 -0000 Received: from localhost (stewart@localhost) by nexus.carleton.ca (8.9.3/8.9.3) with ESMTP id SAA16389; Tue, 10 Aug 1999 18:50:02 -0400 Date: Tue, 10 Aug 1999 18:50:02 -0400 (EDT) From: "Rod m. Stewart" To: Gordon Neal cc: gcc@gcc.gnu.org Subject: Re: build of glibc-2.1.1 using gcc-2.9.5 In-Reply-To: <003a01bee381$437d3d00$5acb6689@pdxnw392.pdx.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Aug 1999, Gordon Neal wrote: > Greetings, > I can't build/configure glibc-2.1.1 using gcc-2.9.5. I get the following > messages: [...] > checking for gcc... gcc > checking version of gcc... 2.95, bad [...] > configure: error: > *** Some critical program is missing or too old. > *** Check the INSTALL file for required versions. > > Is there a work-around for this or do I have to use an older version of gcc? Either: -fix the configre script for glibc to allow gcc 2.95 or (most likely the better solution) -grab a copy of (pre2) glibc-2.1.2, which has this fixed. -Rms From gcc-return-8986-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 22:51:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17005 invoked by alias); 10 Aug 1999 22:51:39 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16980 invoked from network); 10 Aug 1999 22:51:37 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 10 Aug 1999 22:51:37 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id PAA01970; Tue, 10 Aug 1999 15:39:19 -0700 Message-Id: <199908102239.PAA01970@zack.bitmover.com> To: "Gordon Neal" cc: gcc@gcc.gnu.org Subject: Re: build of glibc-2.1.1 using gcc-2.9.5 In-Reply-To: Message from "Gordon Neal" of "Tue, 10 Aug 1999 15:39:53 PDT." <003a01bee381$437d3d00$5acb6689@pdxnw392.pdx.intel.com> Date: Tue, 10 Aug 1999 15:39:19 -0700 From: Zack Weinberg "Gordon Neal" wrote: > Greetings, > I can't build/configure glibc-2.1.1 using gcc-2.9.5. I get the following > messages: [...] > checking for gcc... gcc > checking version of gcc... 2.95, bad This is a known bug in glibc-2.1.1. I believe it is fixed in the 2.1.2preX series. zw From gcc-return-8987-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 23:14:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19363 invoked by alias); 10 Aug 1999 23:14:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19278 invoked from network); 10 Aug 1999 23:14:44 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 10 Aug 1999 23:14:44 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990810231441.LAOR9770.mail.rdc1.md.home.com@home.com>; Tue, 10 Aug 1999 16:14:41 -0700 Message-ID: <37B0B2A9.EB1437A6@home.com> Date: Tue, 10 Aug 1999 19:15:53 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Martin v. Loewis" CC: gcc@gcc.gnu.org Subject: Re: C++ Error message question and suggestion. References: <37AFD2B7.15891BA0@home.com> <199908101958.VAA00698@mira.isdn.cs.tu-berlin.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Martin v. Loewis" wrote: > > > What does "`const basic_rcon::pair *' is not a class, struct, or union > > type" as given by: > [...] > > suppose to mean? > > Exactly that: const basic_rcon::pair * is a "pointer type", and > neither a struct, nor a class, nor a union. And - it should be, in the > place where you use it - which is a qualification in a template > instantiation, such as I figured out what it meant eventually. The message should really be more descriptive such as. the type "const basic_rcon::pair *" is a pointer and pointers do not have member functions. or the type "const basic_rcon::pair *" is a pointer and pointers do not have nested classed or typedefs. depednig on what the user is attempting to do. > > Has any one considered an option to produce better formatted error > > messages. > > Not to my knowledge, no. There have been numerous proposals for > improving the error messages, but none that deals with reformatting > them to be more readable. If you can find an algorithm that makes it > more readable, a patch to the compiler would be most welcome. I might work on that if I have the time. -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-8988-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 23:17:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20231 invoked by alias); 10 Aug 1999 23:17:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20216 invoked from network); 10 Aug 1999 23:17:11 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 10 Aug 1999 23:17:11 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.8.7/8.8.7) with ESMTP id QAA16945; Tue, 10 Aug 1999 16:21:01 -0700 To: ramon@jl1.quim.ucm.es Cc: gcc@gcc.gnu.org Subject: Re: Trying to enable access enforcement on typedefs. In-Reply-To: <19990811002714.A21972@jl1.quim.ucm.es> References: <19990811002714.A21972@jl1.quim.ucm.es> X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990810162101I.mitchell@codesourcery.com> Date: Tue, 10 Aug 1999 16:21:01 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 9 The parser currently does name-lookup for types without having context about the functions that is about to start. Therefore doing access control on types will not work correctly. It will be simple to enable the checks once that information is available. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-8989-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 10 23:19:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21068 invoked by alias); 10 Aug 1999 23:19:01 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21050 invoked from network); 10 Aug 1999 23:18:59 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 10 Aug 1999 23:18:59 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA26151; Tue, 10 Aug 1999 16:18:58 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id QAA16537; Tue, 10 Aug 1999 16:18:58 -0700 To: "Ram'on Garc'ia Fern'andez" Cc: gcc@gcc.gnu.org Subject: Re: Trying to enable access enforcement on typedefs. References: <19990811002714.A21972@jl1.quim.ucm.es> From: Jason Merrill Date: 10 Aug 1999 16:18:58 -0700 In-Reply-To: "Ram'on Garc'ia Fern'andez"'s message of "Wed, 11 Aug 1999 00:27:14 +0200" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Ram'on Garc'ia Fern'andez writes: > I suppose that that there are some (probably subtle) problems in the > implementation, and so GCC developers have choosen that it is better > to allow incorrect code than something worse, such as generating incorrect > code or giving an error for a correct program. > Which are there problems? This needs to work: class A { typedef int priv; public: static priv i; }; A::priv A::i; Jason From gcc-return-8990-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 00:02:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26016 invoked by alias); 11 Aug 1999 00:02:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26001 invoked from network); 11 Aug 1999 00:02:26 -0000 Received: from ne.mediaone.net (HELO chmls05.mediaone.net) (24.128.1.70) by egcs.cygnus.com with SMTP; 11 Aug 1999 00:02:26 -0000 Received: from moshier.ne.mediaone.net (moshier.ne.mediaone.net [24.218.56.120]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id TAA14415; Tue, 10 Aug 1999 19:59:11 -0400 (EDT) Date: Tue, 10 Aug 1999 19:59:12 -0400 (EDT) From: Stephen L Moshier X-Sender: moshier@moshier.ne.mediaone.net Reply-To: moshier@mediaone.net To: Toon Moene cc: gcc@gcc.gnu.org Subject: Float constant propagation In-Reply-To: <37B07FBF.75C0076C@moene.indiv.nluug.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > p = 0.1; > ... /* no intervening assignments to p */ > for (i = 0; i < n; i++) > a[i] = 10.0 * p * b[i]; > >could be turned into: > > for (i = 0; i < n; i++) > a[i] = one * b[i]; I did not know this was happening. It is an unpleasant surprise to see that change across a statement boundary. It is just plain anti-social behavior on the part of the compiler. I think it should be rooted out and put under fast-math. From gcc-return-8991-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 00:37:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30635 invoked by alias); 11 Aug 1999 00:37:29 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30620 invoked from network); 11 Aug 1999 00:37:27 -0000 Received: from chmls06.mediaone.net (24.128.1.71) by egcs.cygnus.com with SMTP; 11 Aug 1999 00:37:27 -0000 Received: from moshier.ne.mediaone.net (moshier.ne.mediaone.net [24.218.56.120]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id UAA08003; Tue, 10 Aug 1999 20:34:02 -0400 (EDT) Date: Tue, 10 Aug 1999 20:34:02 -0400 (EDT) From: Stephen L Moshier X-Sender: moshier@moshier.ne.mediaone.net Reply-To: moshier@mediaone.net To: Toon Moene cc: gcc@gcc.gnu.org Subject: Re: How to not fold constants? In-Reply-To: <37B07FBF.75C0076C@moene.indiv.nluug.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > It's not clear from your mail what the C9X standard requires The C9X rule says, roughly speaking, that float constant expressions may be folded only if nothing can possibly go wrong. It goes on to say that not ever folding at all is an acceptable way to implement that rule -- except for the case of static initializations. So I am asking, how do we figure out that an expression is a static initializer? From gcc-return-8992-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 00:57:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1954 invoked by alias); 11 Aug 1999 00:57:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1939 invoked from network); 11 Aug 1999 00:57:16 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 11 Aug 1999 00:57:16 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id RAA23708; Tue, 10 Aug 1999 17:57:13 -0700 (PDT) Received: by kankakee.wrs.com (SMI-8.6/SMI-SVR4) id RAA02232; Tue, 10 Aug 1999 17:57:12 -0700 Date: Tue, 10 Aug 1999 17:57:12 -0700 From: mrs@wrs.com (Mike Stump) Message-Id: <199908110057.RAA02232@kankakee.wrs.com> To: gcc@gcc.gnu.org, ramon@jl1.quim.ucm.es Subject: Re: Trying to enable access enforcement on typedefs. > Date: Wed, 11 Aug 1999 00:27:14 +0200 > From: "Ram'on Garc'ia Fern'andez" > To: gcc@gcc.gnu.org > I have been looking at the GCC source code in order to contribute > access enforcement for typedefs. But to my surprise, it appears to > be intentionally disabled. :-) Not surprising to me. > I suppose that that there are some (probably subtle) problems in the > implementation, and so GCC developers have choosen that it is better > to allow incorrect code than something worse, such as generating > incorrect code or giving an error for a correct program. > Which are there problems? I don't understand this question. I think you mean, why is it disabled. Because no one wants to take the support hit to turn it on, or put another way, someone tried to turn it on, found out it was going to be more time to `fix' it, then they initially thought, and decided to just turn it back off. Jason is that person, I suspect. If he isn't, then I suspect the code goes back to before 1992. Anyway, to fix it, turn it on, test it throughly, resolve all problems found, get wider testing, fix new problems found, repeat. :-) From gcc-return-8993-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 01:04:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2985 invoked by alias); 11 Aug 1999 01:04:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2970 invoked from network); 11 Aug 1999 01:04:27 -0000 Received: from onion.garlic.com (HELO windmill.garlic.com) (208.195.160.130) by egcs.cygnus.com with SMTP; 11 Aug 1999 01:04:27 -0000 Received: from notesgw1.dssi-jcl.com (notesgw1.dssi-jcl.com [208.195.174.9]) by windmill.garlic.com (8.9.1/8.9.1) with SMTP id SAA13110 for ; Tue, 10 Aug 1999 18:04:22 -0700 Received: by notesgw1.dssi-jcl.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 882567CA.0005E8AA ; Tue, 10 Aug 1999 18:04:32 -0700 X-Lotus-FromDomain: DSSI From: "Tom Williams" To: egcs@egcs.cygnus.com Message-ID: <882567C9.008340B2.00@notesgw1.dssi-jcl.com> Date: Tue, 10 Aug 1999 16:53:50 -0700 Subject: gcc-2.95 on AIX Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi! I was wondering if any of you out there in egcs land use gcc as your primary compiler on AIX? I've been able to build the gcc-2.95 release just fine and it runs great, but I find that I have to still use IBM's C/C++ compiler because gcc can't compile some of the AIX headers and stuff properly. In one case, I got an error about libgcc.a not being found while trying to build tcl8.1.1. I installed egcs/gcc because I had problems getting Apache 1.3.6 to run correctly when compiled with IBM's compiler. Should I even try to use gcc on AIX or just try to live the IBM's compiler? I've been to the www.bull.de site to get binaries for stuff, but some things I need to configure differently and I have to recompile to get me configuration. Any words of wisdom? Thanks in advance for your time. Peace...... Tom From gcc-return-8994-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 02:11:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7131 invoked by alias); 11 Aug 1999 02:11:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7116 invoked from network); 11 Aug 1999 02:11:27 -0000 Received: from igw2.watson.ibm.com (198.81.209.6) by egcs.cygnus.com with SMTP; 11 Aug 1999 02:11:27 -0000 Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw2.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id WAA04522; Tue, 10 Aug 1999 22:11:16 -0400 Received: from marc.watson.ibm.com (marc.watson.ibm.com [9.2.176.11]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id WAA11434; Tue, 10 Aug 1999 22:11:15 -0400 Received: from localhost by marc.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA37806; Tue, 10 Aug 1999 22:11:15 -0400 Message-Id: <9908110211.AA37806@marc.watson.ibm.com> To: "Tom Williams" Cc: egcs@egcs.cygnus.com Subject: Re: gcc-2.95 on AIX In-Reply-To: Message from "Tom Williams" of "Tue, 10 Aug 1999 16:53:50 PDT." <882567C9.008340B2.00@notesgw1.dssi-jcl.com> Date: Tue, 10 Aug 1999 22:11:15 -0400 From: David Edelsohn GCC-2.95 should be completely useable on AIX. Using it as a "primary" compiler is a different question. libgcc.a not found is an installation error or the tcl Makefile using some incorrect options that confict with GCC (e.g., -b). |> ... gcc can't compiler some of the AIX headers and stuff properly... Unless you are using non "fixed" headers or something is broken with an AIX header, GCC should work with AIX headers. I don't know what "stuff" is. If you have a bug, it would be much more helpful for you to submit a bug report following the guidelines for how to submit a useful, complete bug report than sending this very vague message. David From gcc-return-8995-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 03:09:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10530 invoked by alias); 11 Aug 1999 03:09:24 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10515 invoked from network); 11 Aug 1999 03:09:23 -0000 Received: from law2-f174.hotmail.com (HELO hotmail.com) (216.32.181.174) by egcs.cygnus.com with SMTP; 11 Aug 1999 03:09:23 -0000 Received: (qmail 7813 invoked by uid 0); 11 Aug 1999 03:08:47 -0000 Message-ID: <19990811030847.7812.qmail@hotmail.com> Received: from 208.24.140.118 by www.hotmail.com with HTTP; Tue, 10 Aug 1999 20:08:47 PDT X-Originating-IP: [208.24.140.118] From: "Bogus User" To: gcc@gcc.gnu.org Subject: Don't know if this is a bug or not ... Date: Tue, 10 Aug 1999 20:08:47 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed When I try to compile the following code class exc{ public: exc(){ } }; void main(){ (1<2)?0:throw exc(); } I get the error "converting to `void' from `int'" I've tried with egcs and gcc-2.95 and they both give the error. Should this be an error? Thanks, Rich _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From gcc-return-8996-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 04:16:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13574 invoked by alias); 11 Aug 1999 04:15:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13559 invoked from network); 11 Aug 1999 04:15:55 -0000 Received: from vortex.seaspace.com (192.150.113.1) by egcs.cygnus.com with SMTP; 11 Aug 1999 04:15:55 -0000 Received: from maul (maul [192.150.113.32]) by vortex.seaspace.com (8.9.0/8.9.0) with SMTP id VAA27848; Tue, 10 Aug 1999 21:15:53 -0700 (PDT) Message-ID: <007701bee3b0$33d997c0$207196c0@seaspace.com> From: "Doug Semler" To: "Bogus User" , References: <19990811030847.7812.qmail@hotmail.com> Subject: Re: Don't know if this is a bug or not ... Date: Tue, 10 Aug 1999 21:15:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 ----- Original Message ----- From: Bogus User To: Sent: Tuesday, August 10, 1999 8:08 PM Subject: Don't know if this is a bug or not ... > When I try to compile the following code > > class exc{ > public: > exc(){ } > }; > > void main(){ > (1<2)?0:throw exc(); > } > > > I get the error > "converting to `void' from `int'" > > I've tried with egcs and gcc-2.95 and they both give the error. Should this > be an error? Read a C++ book and find out about main() and its return value. --- Doug Semler | qbht@frnfcnpr.pbz Least Senior Software Developer | Garbage In -- Gospel Out Low Man on the Totem Pole | Bus Error (passengers dumped) Minister of Obnoxious Signatures | BAAWA, Long live her majesty IPU Holder of Past Knowledge | AA # lost in move to real job Pioneer Preference Status O- | -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/M d---(pu) s++:- a-- C++ UILSH+++$ P--- L++ E--- W+ N++ o-- K? w--(++$) O- M-- V- PS+ !PE Y PGP t(+) 5+++ X+ R- tv+(-) b+(++) DI++++ D G e++>++++ h!>--- r% y+>+++++** ------END GEEK CODE BLOCK------ From gcc-return-8997-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 04:36:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15070 invoked by alias); 11 Aug 1999 04:36:30 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15055 invoked from network); 11 Aug 1999 04:36:24 -0000 Received: from vortex.seaspace.com (192.150.113.1) by egcs.cygnus.com with SMTP; 11 Aug 1999 04:36:24 -0000 Received: from maul (maul [192.150.113.32]) by vortex.seaspace.com (8.9.0/8.9.0) with SMTP id VAA27944; Tue, 10 Aug 1999 21:36:23 -0700 (PDT) Message-ID: <007d01bee3b3$10ed7080$207196c0@seaspace.com> From: "Doug Semler" To: "Bogus User" , References: <19990811030847.7812.qmail@hotmail.com> <007701bee3b0$33d997c0$207196c0@seaspace.com> Subject: Re: Don't know if this is a bug or not ... Date: Tue, 10 Aug 1999 21:36:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 ----- Original Message ----- From: Doug Semler To: Bogus User ; Sent: Tuesday, August 10, 1999 9:15 PM Subject: Re: Don't know if this is a bug or not ... > ----- Original Message ----- > From: Bogus User > To: > Sent: Tuesday, August 10, 1999 8:08 PM > Subject: Don't know if this is a bug or not ... > > > > When I try to compile the following code > > > > class exc{ > > public: > > exc(){ } > > }; > > > > void main(){ > > (1<2)?0:throw exc(); > > } > > > > > > I get the error > > "converting to `void' from `int'" > > > > I've tried with egcs and gcc-2.95 and they both give the error. Should > this > > be an error? > > > > Read a C++ book and find out about main() and its return value. > I hate responding to myself, but I messed up..., hit SEND button instead of File Menu bar Anyway, I was under the same impression that you are...the result should be int and an r-value...it shouldn't be an error.... --- Doug Semler | qbht@frnfcnpr.pbz Least Senior Software Developer | Garbage In -- Gospel Out Low Man on the Totem Pole | Bus Error (passengers dumped) Minister of Obnoxious Signatures | BAAWA, Long live her majesty IPU Holder of Past Knowledge | AA # lost in move to real job Pioneer Preference Status O- | -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/M d---(pu) s++:- a-- C++ UILSH+++$ P--- L++ E--- W+ N++ o-- K? w--(++$) O- M-- V- PS+ !PE Y PGP t(+) 5+++ X+ R- tv+(-) b+(++) DI++++ D G e++>++++ h!>--- r% y+>+++++** ------END GEEK CODE BLOCK------ From gcc-return-8998-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 04:38:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16059 invoked by alias); 11 Aug 1999 04:38:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16022 invoked from network); 11 Aug 1999 04:37:55 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 11 Aug 1999 04:37:55 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id WAA06936; Tue, 10 Aug 1999 22:33:22 -0600 X-Mailer: exmh version 2.0.2 To: Toon Moene cc: Joern Rennecke , moshier@mediaone.net, gcc@gcc.gnu.org Subject: Re: How to not fold constants? Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 11 Aug 1999 00:31:35 +0200. <37B0A847.B4EC8D0A@moene.indiv.nluug.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Aug 1999 22:33:22 -0600 Message-ID: <6933.934346002@upchuck.cygnus.com> From: Jeffrey A Law In message <37B0A847.B4EC8D0A@moene.indiv.nluug.nl>you write: > > Yes. There might be integer expressions inside that we want to fold. > > Is that true - shouldn't the *frontend* decide how to interpret mixed > mode expressions ? Or is fold-const.c so tied up with C that the > Fortran frontend probably shouldn't use it ?!? fold-const.c is supposed to be generic enough to be used by any front end. If we need to extend the tree structures to indicate when certain folds are safe vs not safe, then that's the way to deal with these problems. Similarly for the folding routines found in cse & combine; they are supposed to be language independent. jeff From gcc-return-8999-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 04:39:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16492 invoked by alias); 11 Aug 1999 04:38:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16463 invoked from network); 11 Aug 1999 04:38:55 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 11 Aug 1999 04:38:55 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id WAA06951; Tue, 10 Aug 1999 22:35:20 -0600 X-Mailer: exmh version 2.0.2 To: moshier@mediaone.net cc: Toon Moene , gcc@gcc.gnu.org Subject: Re: How to not fold constants? Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 10 Aug 1999 20:34:02 EDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Aug 1999 22:35:19 -0600 Message-ID: <6948.934346119@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > > > It's not clear from your mail what the C9X standard requires > > The C9X rule says, roughly speaking, that float constant expressions > may be folded only if nothing can possibly go wrong. It goes on to > say that not ever folding at all is an acceptable way to implement > that rule -- except for the case of static initializations. > > So I am asking, how do we figure out that an expression is a > static initializer? I'm not aware of any such way off the top of my head. You may need to create one, probably by extending "fold" to accept and pass through an argument which indicates that you're trying to fold an initializer. Then change the callers in an appropriate manner. jeff From gcc-return-9000-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 05:03:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22485 invoked by alias); 11 Aug 1999 05:03:36 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22465 invoked from network); 11 Aug 1999 05:03:33 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 11 Aug 1999 05:03:33 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id XAA07098; Tue, 10 Aug 1999 23:00:53 -0600 X-Mailer: exmh version 2.0.2 To: John Wehle cc: zack@bitmover.com, gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 10 Aug 1999 15:43:53 EDT. <199908101943.PAA01276@jwlab.FEITH.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Aug 1999 23:00:53 -0600 Message-ID: <7095.934347653@upchuck.cygnus.com> From: Jeffrey A Law In message <199908101943.PAA01276@jwlab.FEITH.COM>you write: > processors (as you have apparentally noticed :-). The various > ix86 patterns in i386.md attempt to avoid word instructions > when possible so to hopefully produce better code, however at > times they just make the situation worse. Consider the following: > > 1) A 16 bit write to a register immediately followed by a 32 bit read > of the register. This will cause a stall. Converting the 16 bit > write to a 32 bit write avoids the stall, however this may cause a > stall with an earlier instruction (if I recall correctly). > > 2) A 16 bit write to a register followed by several other instructions > which don't reference the register followed by a 32 bit read of the > register. This will not stall. > > Really the code needs to do more analysis and scheduling to properly handle > the issue of avoiding the prefix and partial register stalls. Any takers? > :-) Good summary. I think the key thing to remember is sometimes the transformations which promote the operation from 8/16 bits to 32bits will generate slower code, sometimes they will generate faster code. Thus, just ripping the code out is the wrong approach. While it will help Zack's problem, it is just as likely to cause someone else's example to crawl. Instead we need to do more analysis to determine when it is profitable to promote from 8/16 bit operations to 32bit operations. jeff From gcc-return-9001-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 05:05:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23356 invoked by alias); 11 Aug 1999 05:05:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23341 invoked from network); 11 Aug 1999 05:05:23 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 11 Aug 1999 05:05:23 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id XAA07112; Tue, 10 Aug 1999 23:02:56 -0600 X-Mailer: exmh version 2.0.2 To: Zack Weinberg cc: John Wehle , gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 10 Aug 1999 13:10:23 PDT. <199908102010.NAA16248@zack.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Aug 1999 23:02:56 -0600 Message-ID: <7109.934347776@upchuck.cygnus.com> From: Jeffrey A Law > Does this include something like this? > > movzbw %dl, %ax > addl %eax, %esi > > It certainly sounds like it, and would explain why such a tiny > difference turns into a 2x performance loss. I believe so, yes. However, if the destination of such an insn is not inside a strict_low_part, we can probably turn the first instruction into a movzbl. That would avoid the partial register stall between the movzb/add, but could potentially introduce a stall with an earlier insn. jeff From gcc-return-9002-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 05:09:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24498 invoked by alias); 11 Aug 1999 05:09:12 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24481 invoked from network); 11 Aug 1999 05:09:10 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 11 Aug 1999 05:09:10 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id XAA07140; Tue, 10 Aug 1999 23:05:37 -0600 X-Mailer: exmh version 2.0.2 To: Mark Klein cc: gcc@gcc.gnu.org Subject: Re: muldi3, divdi3 and remdi3 patterns Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 10 Aug 1999 08:58:03 PDT. <4.1.19990810085233.00c17300@garfield.dis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Aug 1999 23:05:37 -0600 Message-ID: <7137.934347937@upchuck.cygnus.com> From: Jeffrey A Law In message <4.1.19990810085233.00c17300@garfield.dis.com>you write: > PA 1.0 is the primary reason - many of the HP3000's are still PA 1.0 > boxes without xmpyu. Regardless, it's the $$rem.. millicode that I'm > trying to add. Then you would want to tune the costs of the multiply, divide & remainders. What's out there is already aware of PA1.0 vs PA1.1 processors, but may not be aware of the relative cost of operations for DImode operations. jeff From gcc-return-9003-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 05:13:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26040 invoked by alias); 11 Aug 1999 05:13:29 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26015 invoked from network); 11 Aug 1999 05:13:17 -0000 Received: from ns.amur.rosnet.ru (root@195.90.168.1) by egcs.cygnus.com with SMTP; 11 Aug 1999 05:13:17 -0000 Received: from localhost (robocop@localhost) by ns.amur.rosnet.ru (8.9.3/8.9.1) with ESMTP id QAA24392; Wed, 11 Aug 1999 16:24:10 +1100 Date: Wed, 11 Aug 1999 16:24:08 +1100 (VLAST) From: Alexander Sokolov To: Zack Weinberg cc: John Wehle , gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic In-Reply-To: <199908102010.NAA16248@zack.bitmover.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Aug 1999, Zack Weinberg wrote: > Does this include something like this? > > movzbw %dl, %ax > addl %eax, %esi Yes, it does. When 32-bit register is read or written after 8- or 16-bit register has been written, this will cause patial register stall on P6 family. -- Alexander Sokolov System Administrator ROSNET Komsomolsk-na-Amure Tel./Fax: +7-095-737-6260 From gcc-return-9004-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 05:36:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28180 invoked by alias); 11 Aug 1999 05:36:36 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28154 invoked from network); 11 Aug 1999 05:36:32 -0000 Received: from rtl.cygnus.com (HELO gluttony.geoffk.wattle.id.au) (205.180.230.21) by egcs.cygnus.com with SMTP; 11 Aug 1999 05:36:32 -0000 Received: (from geoffk@localhost) by gluttony.geoffk.wattle.id.au (8.9.3/8.9.3) id PAA00873; Wed, 11 Aug 1999 15:30:26 +1000 To: egcs@gcc.gnu.org Subject: Re: How to not fold constants? References: <6933.934346002@upchuck.cygnus.com> From: Geoff Keating Date: 11 Aug 1999 15:30:25 +1000 In-Reply-To: Jeffrey A Law's message of "Tue, 10 Aug 1999 22:33:22 -0600" Message-ID: Lines: 35 X-Mailer: Gnus v5.5/Emacs 20.3 Jeffrey A Law writes: > In message <37B0A847.B4EC8D0A@moene.indiv.nluug.nl>you write: > > > Yes. There might be integer expressions inside that we want to fold. > > > > Is that true - shouldn't the *frontend* decide how to interpret mixed > > mode expressions ? Or is fold-const.c so tied up with C that the > > Fortran frontend probably shouldn't use it ?!? > fold-const.c is supposed to be generic enough to be used by any front end. If > we need to extend the tree structures to indicate when certain folds are safe > vs not safe, then that's the way to deal with these problems. > > Similarly for the folding routines found in cse & combine; they are supposed to > be language independent. cse (& combine?) will need to be changed at a higher level; if you have #pragma STDC FENV_ACCESS ON void foo(void); double bar(double x) { double y; y = x + x; foo(void); y += x + x; return y; } you must still perform three '+' operations, despite the common subexpression, because foo() may change the rounding mode or test the exception flags (the addition may overflow, for instance). -- Geoffrey Keating From gcc-return-9005-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 05:58:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29713 invoked by alias); 11 Aug 1999 05:58:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29694 invoked from network); 11 Aug 1999 05:57:56 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 11 Aug 1999 05:57:56 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id XAA07335; Tue, 10 Aug 1999 23:54:18 -0600 X-Mailer: exmh version 2.0.2 To: Geoff Keating cc: egcs@gcc.gnu.org Subject: Re: How to not fold constants? Reply-To: law@cygnus.com In-reply-to: Your message of 11 Aug 1999 15:30:25 +1000. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Aug 1999 23:54:18 -0600 Message-ID: <7332.934350858@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > cse (& combine?) will need to be changed at a higher level; if you have No, this does not mean we need to change cse/combine at a higher level. Just that we have to expose to the compiler that a call insn can have more side effects than a call has now. That does not require any kind of high level conceptual changes. jeff From gcc-return-9006-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 06:33:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12 invoked by alias); 11 Aug 1999 06:33: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32757 invoked from network); 11 Aug 1999 06:33:44 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 11 Aug 1999 06:33:44 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id XAA12236; Tue, 10 Aug 1999 23:33:43 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id XAA11828; Tue, 10 Aug 1999 23:33:43 -0700 Date: Tue, 10 Aug 1999 23:33:43 -0700 From: Richard Henderson To: Zack Weinberg Cc: gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Message-ID: <19990810233343.C11798@cygnus.com> References: <199908101852.LAA11338@zack.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199908101852.LAA11338@zack.bitmover.com>; from Zack Weinberg on Tue, Aug 10, 1999 at 11:52:32AM -0700 On Tue, Aug 10, 1999 at 11:52:32AM -0700, Zack Weinberg wrote: > /* Use a 32-bit operation when possible, to avoid the prefix penalty. */ > if (REG_P (operands[0]) > && i386_aligned_p (operands[2]) > && i386_cc_probably_useless_p (insn)) > { The code in question is a performance improvement on P1 and previous cpus. IMO, we should add a !TARGET_PENTIUMPRO to this conditional -- as noted in a similar test in the block above, partial reg stalls are just too painful to risk. r~ From gcc-return-9007-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 07:01:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3145 invoked by alias); 11 Aug 1999 07:01:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3097 invoked from network); 11 Aug 1999 07:01:41 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 11 Aug 1999 07:01:41 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id AAA13631; Wed, 11 Aug 1999 00:01:41 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id AAA11856; Wed, 11 Aug 1999 00:01:41 -0700 Date: Wed, 11 Aug 1999 00:01:41 -0700 From: Richard Henderson To: John Wehle Cc: zack@bitmover.com, gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Message-ID: <19990811000141.E11798@cygnus.com> References: <199908101943.PAA01276@jwlab.FEITH.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199908101943.PAA01276@jwlab.FEITH.COM>; from John Wehle on Tue, Aug 10, 1999 at 03:43:53PM -0400 On Tue, Aug 10, 1999 at 03:43:53PM -0400, John Wehle wrote: > 1) A 16 bit write to a register immediately followed by a 32 bit read > of the register. This will cause a stall. Converting the 16 bit > write to a 32 bit write avoids the stall, however this may cause a > stall with an earlier instruction (if I recall correctly). No, writes don't stall -- only reads. > 2) A 16 bit write to a register followed by several other instructions > which don't reference the register followed by a 32 bit read of the > register. This will not stall. Incorrect. The 16-bit write instruction has to _retire_ before the 32-bit read can _issue_. With reorder buffers the size that they are, this is 20 odd cycles, worst case. r~ From gcc-return-9008-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 07:15:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6238 invoked by alias); 11 Aug 1999 07:15:44 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6223 invoked from network); 11 Aug 1999 07:15:43 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 11 Aug 1999 07:15:43 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id AAA14109; Wed, 11 Aug 1999 00:15:43 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id AAA11875; Wed, 11 Aug 1999 00:15:42 -0700 Date: Wed, 11 Aug 1999 00:15:42 -0700 From: Richard Henderson To: Jeffrey A Law Cc: John Wehle , zack@bitmover.com, gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Message-ID: <19990811001542.F11798@cygnus.com> References: <199908101943.PAA01276@jwlab.FEITH.COM> <7095.934347653@upchuck.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <7095.934347653@upchuck.cygnus.com>; from Jeffrey A Law on Tue, Aug 10, 1999 at 11:00:53PM -0600 On Tue, Aug 10, 1999 at 11:00:53PM -0600, Jeffrey A Law wrote: > Instead we need to do more analysis to determine when it is profitable to > promote from 8/16 bit operations to 32bit operations. The new_ia32_branch currently just disables all such promotions when TARGET_PARTIAL_REG_STALL. Not ideal, perhaps, but much better than blindly going ahead with the promotions. Yes, a post-reload pass to match up register usage modes would be the ideal solution, but something like that isn't going to go into 2.95.1. IMO going through the 10 to 20 patterns in the existing code base that do such promotions and conditionally disabling them is the only viable course for 2.95. r~ From gcc-return-9009-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 07:59:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12191 invoked by alias); 11 Aug 1999 07:59:36 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12175 invoked from network); 11 Aug 1999 07:59:33 -0000 Received: from penguin-ext.wise.edt.ericsson.se (HELO penguin.wise.edt.ericsson.se) (194.237.142.110) by egcs.cygnus.com with SMTP; 11 Aug 1999 07:59:33 -0000 Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.44.44]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id JAA00238 for ; Wed, 11 Aug 1999 09:59:31 +0200 (MET DST) Received: from uabx01c259.uab.ericsson.se (uabx01c259 [134.138.227.19]) by ms.uab.ericsson.se (8.9.3/8.9.3/uab-1.37) with ESMTP id JAA28329 for ; Wed, 11 Aug 1999 09:59:31 +0200 (MET DST) Received: from uab.ericsson.se by uabx01c259.uab.ericsson.se (8.8.8+Sun/client-1.3) id JAA25954; Wed, 11 Aug 1999 09:59:30 +0200 (MET DST) Message-ID: <37B12D61.99CC4012@uab.ericsson.se> Date: Wed, 11 Aug 1999 09:59:29 +0200 From: Aziz Shammas Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.51C-CCK-MCD [en] (X11; I; SunOS 5.5.1 sun4m) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Questions ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi I need some answer and I hope that you can send it as soon as possible. Do you give suport to gcc and egcs?......... Do I or a company any licence to use gcc & egcs? How much a license cost? Do you resolve Y2k in gcc & egcs ? Do you give any Y2k guarantee on gcc & egcs? THANK YOU VERY MUCH A student from sweden Aziz From gcc-return-9010-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 08:00:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12862 invoked by alias); 11 Aug 1999 08:00:44 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12834 invoked from network); 11 Aug 1999 08:00:41 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 11 Aug 1999 08:00:41 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id BAA07927; Wed, 11 Aug 1999 01:57:20 -0600 X-Mailer: exmh version 2.0.2 To: "Kaveh R. Ghazi" cc: egcs@egcs.cygnus.com Subject: Re: What's the deal with MD_CALL_PROTOTYPES ? Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 10 Aug 1999 13:43:55 EDT. <199908101743.NAA21180@caip.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Aug 1999 01:57:19 -0600 Message-ID: <7924.934358239@upchuck.cygnus.com> From: Jeffrey A Law In message <199908101743.NAA21180@caip.rutgers.edu>you write: > So I'm prototyping stuff in insn-* and I notice that the macro > MD_CALL_PROTOTYPES wraps gen_call() and gen_call_value() in > insn-flags.h. The docs says this: > > > `MD_CALL_PROTOTYPES' > > Define this if you wish to generate prototypes for the `gen_call' > > or `gen_call_value' functions generated from the machine > > description file. If `USE_PROTOTYPES' is defined to be 0, or the > > host compiler does not support prototypes, or `NO_MD_PROTOTYPES' > > is defined, this macro has no effect. As soon as all of the > > machine descriptions are modified to have the appropriate number > > of arguments, this macro will be removed. > > So I was wondering can it be removed? Judging from the insn-flags.h > vs insn-emit.c output, it looks like Irix6 gets it right, but not > solaris2. I'd prefer not to remove it. Instead we should be looking to fix the various backends so that we can enable prototypes for the gen_call* functions. jeff From gcc-return-9011-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 08:57:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17897 invoked by alias); 11 Aug 1999 08:57:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17866 invoked from network); 11 Aug 1999 08:57:18 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 11 Aug 1999 08:57:18 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id CAA08291; Wed, 11 Aug 1999 02:53:51 -0600 X-Mailer: exmh version 2.0.2 To: Joern Rennecke cc: lucier@math.purdue.edu (Brad Lucier), gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, staff@math.purdue.edu, hosking@cs.purdue.edu, wilker@math.purdue.edu, bernds@cygnus.com Subject: Re: big slowdown in egcs-1.1.2->gcc-2.95 on alpha Reply-To: law@cygnus.com In-reply-to: Your message of Sat, 07 Aug 1999 02:39:42 BST. <199908070139.CAA18804@phal.cygnus.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Aug 1999 02:53:50 -0600 Message-ID: <8288.934361630@upchuck.cygnus.com> From: Jeffrey A Law In message <199908070139.CAA18804@phal.cygnus.co.uk>you write: > Hmm, I wonder if the CONFLICT_P tests take a lot of time, or if the rest > of the operations in the inner loop cost more. > > I wonder if this works: > > Thu Aug 5 22:27:15 1999 J"orn Rennecke > > * global.c (prune_preferences): Move some invariants out of the > inner loop. This patch is fine, even if it did not make a significant difference for the compile time slowdown in question. Thanks. jeff From gcc-return-9012-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 09:18:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20155 invoked by alias); 11 Aug 1999 09:18:42 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20140 invoked from network); 11 Aug 1999 09:18:41 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 11 Aug 1999 09:18:41 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id DAA08397; Wed, 11 Aug 1999 03:15:40 -0600 X-Mailer: exmh version 2.0.2 To: Aziz Shammas cc: gcc@gcc.gnu.org Subject: Re: Questions ? Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 11 Aug 1999 09:59:29 +0200. <37B12D61.99CC4012@uab.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Aug 1999 03:15:40 -0600 Message-ID: <8394.934362940@upchuck.cygnus.com> From: Jeffrey A Law In message <37B12D61.99CC4012@uab.ericsson.se>you write: > Do you give suport to gcc and egcs?......... There are companies and individuals who provide support services for gcc/egcs. > Do I or a company any licence to use gcc & egcs? No. > Do you resolve Y2k in gcc & egcs ? > > Do you give any Y2k guarantee on gcc & egcs? You would need to contact one of the support companies or individuals for this kind of stuff. See the file "gcc/SERVICES" in the source distribution. jeff From gcc-return-9013-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 09:25:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22295 invoked by alias); 11 Aug 1999 09:25:52 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22280 invoked from network); 11 Aug 1999 09:25:48 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 11 Aug 1999 09:25:48 -0000 Received: (qmail 23170 invoked by alias); 11 Aug 1999 09:25:46 -0000 Received: (qmail 23165 invoked from network); 11 Aug 1999 09:25:46 -0000 Received: from biriani.cygnus.co.uk (root@194.130.39.16) by dns.cygnus.co.uk with SMTP; 11 Aug 1999 09:25:46 -0000 Received: from localhost by biriani.cygnus.co.uk (UUNET PIPEX simple 1.30) id KAA01172; Wed, 11 Aug 1999 10:25:42 +0100 Date: Wed, 11 Aug 1999 10:25:42 +0100 (BST) From: Bernd Schmidt To: "Kaveh R. Ghazi" cc: egcs@egcs.cygnus.com Subject: Re: What's the deal with MD_CALL_PROTOTYPES ? In-Reply-To: <199908101743.NAA21180@caip.rutgers.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > So I'm prototyping stuff in insn-* and I notice that the macro > MD_CALL_PROTOTYPES wraps gen_call() and gen_call_value() in > insn-flags.h. The docs says this: > > > `MD_CALL_PROTOTYPES' > > Define this if you wish to generate prototypes for the `gen_call' > > or `gen_call_value' functions generated from the machine > > description file. If `USE_PROTOTYPES' is defined to be 0, or the > > host compiler does not support prototypes, or `NO_MD_PROTOTYPES' > > is defined, this macro has no effect. As soon as all of the > > machine descriptions are modified to have the appropriate number > > of arguments, this macro will be removed. IIRC the problem is that the call patterns in some machine descriptions don't use all the operands that are passed to them. A normal call without a return value takes three operands, but only the first two of them are used in some ports. So if you generate a prototype for gen_call, you will get errors about wrong number of parameters when the compiler sees a call to gen_call with more than two operands. You could try adding the necessary operands to all call patterns in all machine descriptions (nasty), or you could try to fix it in genflags.c by emitting a known good prototype rather than emitting no prototype at all. Bernd From gcc-return-9014-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 11:35:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29896 invoked by alias); 11 Aug 1999 11:34:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29881 invoked from network); 11 Aug 1999 11:34:56 -0000 Received: from gw-nl3.philips.com (@192.68.44.35) by egcs.cygnus.com with SMTP; 11 Aug 1999 11:34:56 -0000 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl3.philips.com with ESMTP id NAA23789 for ; Wed, 11 Aug 1999 13:34:38 +0200 (MEST) (envelope-from yedema@natlab.research.philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a) id xma023787; Wed, 11 Aug 99 13:34:38 +0200 Received: from natlab.research.philips.com (prle.natlab.research.philips.com [130.139.161.112]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with SMTP id NAA10972 for ; Wed, 11 Aug 1999 13:34:38 +0200 (MET DST) Received: by natlab.research.philips.com; Wed, 11 Aug 1999 13:34:37 +0200 Received: by hpas18.natlab.research.philips.com ; Wed, 11 Aug 1999 13:34:36 +0200 (METDST) To: gcc@gcc.gnu.org Subject: gcc 2.95 build problems but successful From: Wim Yedema Date: 11 Aug 1999 13:34:35 +0200 Message-Id: Lines: 6 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" system: hppa2.0w-hp-hpux11.00 failed with HP as and gas 2.8.1 (target hppa1.1-hp-hpux10.20) successful with gas 2.9.1 (target hppa1.0-hp-hpux11.00) I used hppa1.0-hp-hpux11.00 to configure gcc due to warnings given at the install pages From gcc-return-9015-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 14:18:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30699 invoked by alias); 11 Aug 1999 14:18:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30683 invoked from network); 11 Aug 1999 14:18:47 -0000 Received: from law2-f161.hotmail.com (HELO hotmail.com) (216.32.181.161) by egcs.cygnus.com with SMTP; 11 Aug 1999 14:18:46 -0000 Received: (qmail 45272 invoked by uid 0); 11 Aug 1999 14:18:16 -0000 Message-ID: <19990811141816.45271.qmail@hotmail.com> Received: from 192.35.232.115 by www.hotmail.com with HTTP; Wed, 11 Aug 1999 07:18:16 PDT X-Originating-IP: [192.35.232.115] From: "Bogus User" To: doug@seaspace.com Cc: gcc@gcc.gnu.org Subject: Re: Don't know if this is a bug or not ... Date: Wed, 11 Aug 1999 07:18:16 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed > > > When I try to compile the following code > > > > > > class exc{ > > > public: > > > exc(){ } > > > }; > > > > > > void main(){ > > > (1<2)?0:throw exc(); > > > } > > > > > > > > > I get the error > > > "converting to `void' from `int'" > > > > > > I've tried with egcs and gcc-2.95 and they both give the error. >Should > > this > > > be an error? > > > > > > > > Read a C++ book and find out about main() and its return value. > > > >I hate responding to myself, but I messed up..., hit SEND button >instead of File Menu bar > >Anyway, I was under the same impression that you are...the result >should be int and an r-value...it shouldn't be an error.... > Similar code to this compiles ok using VC++ on NT, IBM's C++ on AIX, and Sun's C++ on Solaris. I tried the example I gave on NT and it compiled without errors or warnings. I guess for now I'll just have to code around this problem. Thanks, Rich _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From gcc-return-9016-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 14:55:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2784 invoked by alias); 11 Aug 1999 14:55:35 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2769 invoked from network); 11 Aug 1999 14:55:32 -0000 Received: from garfield.dis.com (199.4.97.30) by egcs.cygnus.com with SMTP; 11 Aug 1999 14:55:32 -0000 Received: from garfield (199.4.97.30) by garfield.dis.com (EMWAC SMTPRS 0.81) with SMTP id ; Wed, 11 Aug 1999 07:55:30 -0700 Message-Id: <4.1.19990811073640.00ce36f0@garfield.dis.com> X-Sender: mark@garfield.dis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 11 Aug 1999 07:55:30 -0700 To: law@cygnus.com From: Mark Klein Subject: Re: muldi3, divdi3 and remdi3 patterns Cc: gcc@gcc.gnu.org In-Reply-To: <7137.934347937@upchuck.cygnus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:05 PM 8/10/99 -0600, Jeffrey A Law wrote: >Then you would want to tune the costs of the multiply, divide & remainders. Let me rephrase my earlier question .. case UDIV: case MOD: case UMOD: return COSTS_N_INSNS (60); Did you base the costs on anything concrete such as number of cycles or instructions per operation, or are these arbitrary values that simply indicate the relative costs? What does the "60" represent? TIA, -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available From gcc-return-9017-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 16:16:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12918 invoked by alias); 11 Aug 1999 16:16:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12902 invoked from network); 11 Aug 1999 16:16:23 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 11 Aug 1999 16:16:23 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id JAA06431; Wed, 11 Aug 1999 09:15:19 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id JAA26854; Wed, 11 Aug 1999 09:15:18 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id JAA12106; Wed, 11 Aug 1999 09:15:18 -0700 Message-Id: <199908111615.JAA12106@atrus.synopsys.com> Subject: Re: Questions ? To: law@cygnus.com Date: Wed, 11 Aug 99 9:15:17 PDT Cc: uabazes@uab.ericsson.se, gcc@gcc.gnu.org In-Reply-To: <8394.934362940@upchuck.cygnus.com>; from "Jeffrey A Law" at Aug 11, 99 3:15 am X-Mailer: ELM [version 2.3 PL11] Aziz Shammas writes: > In message <37B12D61.99CC4012@uab.ericsson.se>you write: > > Do you give suport to gcc and egcs?......... To clarify: egcs and the FSF gcc have re-merged. The former egcs compiler has been released as GCC version 2.95, and all subsequent GCC releases will come from the egcs source tree. Jeff Law writes: > There are companies and individuals who provide support services for > gcc/egcs. and most of those people are on this list, but they try to keep things company-neutral. > > Do I or a company any licence to use gcc & egcs? > No. That is, you do not need to pay a fee or sign a license agreement. > > Do you resolve Y2k in gcc & egcs ? > > > > Do you give any Y2k guarantee on gcc & egcs? > You would need to contact one of the support companies or individuals for > this kind of stuff. To clarify: there are no known Y2k problems in gcc, and a number of developers have been hunting for such problems. However, since gcc is free software, there is no warranty or promise on this issue. Unofficially, you are pretty safe. If for business reasons you need some kind of certification or warranty, then I second Jeff's suggestion that you look into a support agreement. > See the file "gcc/SERVICES" in the source distribution. From gcc-return-9018-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 17:31:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19163 invoked by alias); 11 Aug 1999 17:31:23 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19148 invoked from network); 11 Aug 1999 17:31:15 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 11 Aug 1999 17:31:15 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id KAA04075; Wed, 11 Aug 1999 10:23:25 -0700 Message-Id: <199908111723.KAA04075@zack.bitmover.com> To: Richard Henderson cc: Jeffrey A Law , John Wehle , gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic In-Reply-To: Message from Richard Henderson of "Wed, 11 Aug 1999 00:15:42 PDT." <19990811001542.F11798@cygnus.com> Date: Wed, 11 Aug 1999 10:23:25 -0700 From: Zack Weinberg Richard Henderson wrote: > On Tue, Aug 10, 1999 at 11:00:53PM -0600, Jeffrey A Law wrote: > > Instead we need to do more analysis to determine when it is profitable to > > promote from 8/16 bit operations to 32bit operations. > > The new_ia32_branch currently just disables all such promotions when > TARGET_PARTIAL_REG_STALL. Not ideal, perhaps, but much better than > blindly going ahead with the promotions. > > Yes, a post-reload pass to match up register usage modes would be the > ideal solution, but something like that isn't going to go into 2.95.1. > > IMO going through the 10 to 20 patterns in the existing code base > that do such promotions and conditionally disabling them is the only > viable course for 2.95. If I make a patch to do this, will it be accepted for 2.95.1? For 2.96/the new_ia32_branch, I wonder if it would be possible to use the peephole2 framework you posted to widen register operations throughout a function. Going back to the sample code I posted... .L3: movb (%ebx),%dl # 26 movqi+1/1 incl %ebx # 27 addsi3+1/1 testb %dl,%dl # 29 tstqi_1 je .L4 # 30 bleu+1 movzbw %dl,%ax # 35 zero_extendqihi2+1 addl %eax,%esi # 37 addhi3+1/1 movb %dl,(%ecx) # 41 movqi+1/3 incl %ecx # 42 addsi3+1/1 cmpb $10,%dl # 44 cmpqi_1/2 jne .L3 # 45 bleu+1 .L4: I wonder if it wouldn't be profitable to do the extend at the same time as the fetch, like this: .L3: movzbl (%ebx),%edx incl %ebx testb %dl,%dl je .L4 addl %edx,%esi movb %dl,(%ecx) incl %ecx cmpb $10,%dl jne .L3 .L4: This is three bytes smaller and uses one fewer register, and I don't think it's any worse in decode penalties or whatever. zw From gcc-return-9019-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 18:14:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24996 invoked by alias); 11 Aug 1999 18:14:29 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24953 invoked from network); 11 Aug 1999 18:14:17 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 11 Aug 1999 18:14:17 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id MAA09264; Wed, 11 Aug 1999 12:11:41 -0600 X-Mailer: exmh version 2.0.2 To: Zack Weinberg cc: Richard Henderson , John Wehle , gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 11 Aug 1999 10:23:25 PDT. <199908111723.KAA04075@zack.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Aug 1999 12:11:41 -0600 Message-ID: <9261.934395101@upchuck.cygnus.com> From: Jeffrey A Law In message <199908111723.KAA04075@zack.bitmover.com>you write: > If I make a patch to do this, will it be accepted for 2.95.1? No. gcc-2.95.1 is for critical bugfixes. This is not qualify. jeff From gcc-return-9020-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 18:23:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26953 invoked by alias); 11 Aug 1999 18:23:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26934 invoked from network); 11 Aug 1999 18:23:23 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 11 Aug 1999 18:23:22 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA11895; Wed, 11 Aug 1999 11:23:21 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id LAA12638; Wed, 11 Aug 1999 11:23:21 -0700 Date: Wed, 11 Aug 1999 11:23:21 -0700 From: Richard Henderson To: Zack Weinberg Cc: Jeffrey A Law , John Wehle , gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Message-ID: <19990811112321.C12613@cygnus.com> References: <199908111723.KAA04075@zack.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199908111723.KAA04075@zack.bitmover.com>; from Zack Weinberg on Wed, Aug 11, 1999 at 10:23:25AM -0700 On Wed, Aug 11, 1999 at 10:23:25AM -0700, Zack Weinberg wrote: > For 2.96/the new_ia32_branch, I wonder if it would be possible to > use the peephole2 framework you posted to widen register operations > throughout a function. Nope. Such a pass needs a global view of the function. A peepholer, by nature, does not have that. > I wonder if it wouldn't be profitable to do the extend at the same > time as the fetch, like this: Yes. r~ From gcc-return-9021-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 18:24:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27529 invoked by alias); 11 Aug 1999 18:24:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27283 invoked from network); 11 Aug 1999 18:24:09 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 11 Aug 1999 18:24:09 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id OAA29975; Wed, 11 Aug 1999 14:24:07 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id OAA02878; Wed, 11 Aug 1999 14:24:04 -0400 (EDT) Date: Wed, 11 Aug 1999 14:24:04 -0400 (EDT) From: John Wehle Message-Id: <199908111824.OAA02878@jwlab.FEITH.COM> To: rth@cygnus.com Cc: zack@bitmover.com, gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Content-Type: text >On Tue, Aug 10, 1999 at 03:43:53PM -0400, John Wehle wrote: >> 1) A 16 bit write to a register immediately followed by a 32 bit read >> of the register. This will cause a stall. Converting the 16 bit >> write to a 32 bit write avoids the stall, however this may cause a >> stall with an earlier instruction (if I recall correctly). > > No, writes don't stall -- only reads. Most of the 16 bit patterns in i386.md perform a read prior to the write. Converting (for example) addw to addl means in addition to the write being 32 bits that the read is 32 bits. The stall with an earlier instruction can occur due to the 32 bit read. >> 2) A 16 bit write to a register followed by several other instructions >> which don't reference the register followed by a 32 bit read of the >> register. This will not stall. > > Incorrect. The 16-bit write instruction has to _retire_ before > the 32-bit read can _issue_. With reorder buffers the size that > they are, this is 20 odd cycles, worst case. I'll grant you that my response wasn't as precise as it could have been, however I'm not sure where it's * incorrect *. As a practical matter if I separate a 16 bit write to a register with enough instructions (which hopefully don't have any inherent stall issues of their own :-) doesn't this allow the write to retire which avoids a partial register stall when the 32 bit read instruction is encountered? What did I miss? -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-9022-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 18:37:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31679 invoked by alias); 11 Aug 1999 18:37:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31664 invoked from network); 11 Aug 1999 18:37:13 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 11 Aug 1999 18:37:13 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id LAA04319; Wed, 11 Aug 1999 11:29:24 -0700 Message-Id: <199908111829.LAA04319@zack.bitmover.com> To: law@cygnus.com cc: Richard Henderson , John Wehle , gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic In-Reply-To: Message from Jeffrey A Law of "Wed, 11 Aug 1999 12:11:41 MDT." <9261.934395101@upchuck.cygnus.com> Date: Wed, 11 Aug 1999 11:29:24 -0700 From: Zack Weinberg Jeffrey A Law wrote: > In message <199908111723.KAA04075@zack.bitmover.com>you write: > > If I make a patch to do this, will it be accepted for 2.95.1? > No. gcc-2.95.1 is for critical bugfixes. This is not qualify. Right... then we should focus on improving the new backend for 2.96. An approach occurred to me in the shower: At RTL generation time, pretend that there are no HImode operations other than load/store. For example, we'd produce (set (reg:SI 21) (extend:SI (mem:HI address))) (set (reg:SI 22) (add (reg:SI 21) (const_int 1))) (set (mem:HI address) (subreg:HI (reg:SI 22) 0)) for an increment of a HImode memory location. We do similar things to QImode, except I don't think it's necessary to eliminate all of the patterns there. After reload, we decide how to generate the load-and-extends based on processor type (xor/movw versus movzwl, etc.) This exposes the situation in RTL, which should mean we need less work on the optimizer proper. zw From gcc-return-9023-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 18:43:23 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32669 invoked by alias); 11 Aug 1999 18:43:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32650 invoked from network); 11 Aug 1999 18:43:20 -0000 Received: from onion.garlic.com (HELO windmill.garlic.com) (208.195.160.130) by egcs.cygnus.com with SMTP; 11 Aug 1999 18:43:20 -0000 Received: from notesgw1.dssi-jcl.com (notesgw1.dssi-jcl.com [208.195.174.9]) by windmill.garlic.com (8.9.1/8.9.1) with SMTP id LAA11836; Wed, 11 Aug 1999 11:43:09 -0700 Received: by notesgw1.dssi-jcl.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 882567CA.0066D05E ; Wed, 11 Aug 1999 11:43:00 -0700 X-Lotus-FromDomain: DSSI From: "Tom Williams" To: David Edelsohn cc: egcs@egcs.cygnus.com Message-ID: <882567CA.006041FC.00@notesgw1.dssi-jcl.com> Date: Wed, 11 Aug 1999 10:48:31 -0700 Subject: Re: gcc-2.95 on AIX Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Well, I got one of my problems solved. It turns out that gcc did not like the way that certain #define macros were defined in /usr/include/pthread.h on AIX. Example: Works: #define PTHREAD_ONCE_INIT {0,0,0,0} Fails: /* #define PTHREAD_ONCE_INIT {0,\ 0,\ 0,\ 0} */ Once I touched up the macros with the slashes for line continutation, my program compiled. I was building glib-1.2.3 using gcc-2.95 on AIX 4.3.1. I configured glib like this: configure --prefix/usr/local/glib --with-threads=posix I put the modified pthread.h in the gthread directory in the glib source tree and changed gthread-posix.c to use my touched up pthread.h and everybody was happy again. Does this sound like a gcc bug? I'm going to try to build glib again with the "-traditional" switch to see if that changes anything. If this sounds like a bug, I'll gather more data to submit a formal bug report. I've never done that before so please bear with me. Peace..... Tom David Edelsohn on 08/10/99 07:11:15 PM To: Tom Williams/HQ/dssi cc: egcs@egcs.cygnus.com Subject: Re: gcc-2.95 on AIX GCC-2.95 should be completely useable on AIX. Using it as a "primary" compiler is a different question. libgcc.a not found is an installation error or the tcl Makefile using some incorrect options that confict with GCC (e.g., -b). |> ... gcc can't compiler some of the AIX headers and stuff properly... Unless you are using non "fixed" headers or something is broken with an AIX header, GCC should work with AIX headers. I don't know what "stuff" is. If you have a bug, it would be much more helpful for you to submit a bug report following the guidelines for how to submit a useful, complete bug report than sending this very vague message. David From gcc-return-9024-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 19:04:12 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3492 invoked by alias); 11 Aug 1999 19:04:02 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3469 invoked from network); 11 Aug 1999 19:03:57 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 11 Aug 1999 19:03:57 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id NAA09455; Wed, 11 Aug 1999 13:01:23 -0600 X-Mailer: exmh version 2.0.2 To: Zack Weinberg cc: Richard Henderson , John Wehle , gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 11 Aug 1999 11:29:24 PDT. <199908111829.LAA04319@zack.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Aug 1999 13:01:23 -0600 Message-ID: <9452.934398083@upchuck.cygnus.com> From: Jeffrey A Law In message <199908111829.LAA04319@zack.bitmover.com>you write: > Right... then we should focus on improving the new backend for 2.96. > An approach occurred to me in the shower: > > At RTL generation time, pretend that there are no HImode operations > other than load/store. For example, we'd produce rth has already tried this and reported that it was generally a lose. We already have these kinds of capabilities because most risc chips work in this manner. jeff From gcc-return-9025-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 19:16:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6025 invoked by alias); 11 Aug 1999 19:16:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5967 invoked from network); 11 Aug 1999 19:16:10 -0000 Received: from igw2.watson.ibm.com (198.81.209.6) by egcs.cygnus.com with SMTP; 11 Aug 1999 19:16:10 -0000 Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw2.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id PAA15836; Wed, 11 Aug 1999 15:15:53 -0400 Received: from marc.watson.ibm.com (marc.watson.ibm.com [9.2.176.11]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id PAA21738; Wed, 11 Aug 1999 15:15:53 -0400 Received: from localhost by marc.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA30984; Wed, 11 Aug 1999 15:15:53 -0400 Message-Id: <9908111915.AA30984@marc.watson.ibm.com> To: "Tom Williams" Cc: egcs@egcs.cygnus.com Subject: Re: gcc-2.95 on AIX In-Reply-To: Message from "Tom Williams" of "Wed, 11 Aug 1999 10:48:31 PDT." <882567CA.006041FC.00@notesgw1.dssi-jcl.com> Date: Wed, 11 Aug 1999 15:15:52 -0400 From: David Edelsohn I naively tried including the unmodified pthread.h in AIX 4.3.2 /usr/include into a toy program and did not receive any errors. Would you please send a SMALL test program which fails and describe exactly what error you are experiencing. As an aside, to compile a pthreads program on AIX using GCC you need to compile each object file and link with -mthreads option. David From gcc-return-9026-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 20:08:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13924 invoked by alias); 11 Aug 1999 20:08:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13906 invoked from network); 11 Aug 1999 20:07:59 -0000 Received: from law2-f258.hotmail.com (HELO hotmail.com) (216.32.180.216) by egcs.cygnus.com with SMTP; 11 Aug 1999 20:07:59 -0000 Received: (qmail 71592 invoked by uid 0); 11 Aug 1999 20:08:25 -0000 Message-ID: <19990811200825.71591.qmail@hotmail.com> Received: from 192.35.232.14 by www.hotmail.com with HTTP; Wed, 11 Aug 1999 13:08:25 PDT X-Originating-IP: [192.35.232.14] From: "Bogus User" To: gcc@gcc.gnu.org Subject: A couple of questions Date: Wed, 11 Aug 1999 13:08:25 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed First question: what does the error message "common_type called with uncommon member types (compiler error)" mean? I'm getting it when I compile a large program and I can't seem to reproduce it with a small example. Second question: gcc-2.95 seems to think that "export" is a reserved word in C++, but all it does is ignore it. Is there any way to tell it that "export" is not a reserved word? Thanks, Rich _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From gcc-return-9027-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 20:08:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14008 invoked by alias); 11 Aug 1999 20:08:06 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13670 invoked from network); 11 Aug 1999 20:07:00 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 11 Aug 1999 20:07:00 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id RAA12553; Wed, 11 Aug 1999 17:01:30 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id RAA15718; Wed, 11 Aug 1999 17:01:32 -0300 (EST) To: xxx Cc: gcc@gcc.gnu.org Subject: Re: can't find libstdc++ References: <37AA38A6.AF0114C7@perpetuallink.com.au> From: Alexandre Oliva Date: 11 Aug 1999 17:05:25 -0300 In-Reply-To: xxx's message of "Fri, 06 Aug 1999 11:21:42 +1000" Message-ID: Lines: 14 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 5, 1999, xxx wrote: > After compiling gcc2.95, thecompilation of a C++ program failed > because it can't find libstdc++. How do I fix this problem? Did you `make install'? It should find libstdc++ automatically, unless you failed to build g++ and libstdc++. Or maybe you're linking with gcc instead of g++? -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9028-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 20:49:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22444 invoked by alias); 11 Aug 1999 20:49:11 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22418 invoked from network); 11 Aug 1999 20:49:08 -0000 Received: from p13-cable.paradise.net.nz (HELO g8labs.co.nz) (203.96.144.13) by egcs.cygnus.com with SMTP; 11 Aug 1999 20:49:08 -0000 Received: from rincewind [192.168.0.33] by g8labs.co.nz [127.0.0.1] with SMTP (MDaemon.v2.7.SP4.R) for ; Thu, 12 Aug 1999 08:47:05 +1200 From: "Jonathan Couper" To: Subject: PA-8500 vs. PA-8000 - gcc support? Date: Thu, 12 Aug 1999 08:47:05 +1200 Message-ID: <001401bee43a$ab87ea80$2100a8c0@rincewind.g8labs.co.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-MDaemon-Deliver-To: gcc@gcc.gnu.org X-Return-Path: couper@g8labs.co.nz Hiya We're using a PA-8000 machine, but are expecting to port to PA-8500 later in the year. I'm curious to know: - Does gcc have specific support for the 8500? - Is there any significant difference between the two? Any info will be much appreciated...! Jonathan Couper couper@g8labs.co.nz ==================================================== Jonathan Couper ICQ# 22359323 G8 Labs (NZ) Ltd. P.O. Box 13449, Johnsonville, Wellington, New Zealand Ph. +64-4-9393377 Fx. +64-4-9393390 ==================================================== We are nothing but the sum of our prejudices. From gcc-return-9029-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 20:50:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22889 invoked by alias); 11 Aug 1999 20:50:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22802 invoked from network); 11 Aug 1999 20:49:59 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 11 Aug 1999 20:49:59 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id RAA13539; Wed, 11 Aug 1999 17:44:57 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id RAA20971; Wed, 11 Aug 1999 17:44:53 -0300 (EST) To: "Bogus User" Cc: gcc@gcc.gnu.org Subject: Re: A couple of questions References: <19990811200825.71591.qmail@hotmail.com> From: Alexandre Oliva Date: 11 Aug 1999 17:48:46 -0300 In-Reply-To: "Bogus User"'s message of "Wed, 11 Aug 1999 13:08:25 PDT" Message-ID: Lines: 29 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 11, 1999, "Bogus User" wrote: > "common_type called with uncommon member types (compiler error)" > mean? I'm getting it when I compile a large program and I can't seem to > reproduce it with a small example. Then post the large program, if possible. See http://egcs.cygnus.com/faq.html#bugreport > Second question: gcc-2.95 seems to think that "export" is a reserved word > in C++ It is. > but all it does is ignore it. Right. In g++, it's currently ``reserved for future use''. By helping you avoid its mis-uses, it's saving you from wasting time in the future. > Is there any way to tell it that "export" is not a reserved word? Other than -Dexport=export_that_is_not_reserved ? -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9030-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 21:27:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27731 invoked by alias); 11 Aug 1999 21:27:39 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27700 invoked from network); 11 Aug 1999 21:27:24 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 11 Aug 1999 21:27:24 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id SAA14666; Wed, 11 Aug 1999 18:22:51 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id RAA15835; Wed, 11 Aug 1999 17:02:28 -0300 (EST) To: Eric Lemings Cc: gcc@gcc.gnu.org, gcc-help@gcc.gnu.org Subject: Re: *_FOR_TARGET Makefile macros References: <37A9D6C2.A4C7D764@lmco.com> From: Alexandre Oliva Date: 11 Aug 1999 17:06:18 -0300 In-Reply-To: Eric Lemings's message of "Thu, 05 Aug 1999 12:24:02 -0600" Message-ID: Lines: 14 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 5, 1999, Eric Lemings wrote: > What is the difference between * macros (e.g., CFLAGS) and *_FOR_TARGET > macros (e.g., CFLAGS_FOR_TARGET) in the top-level Makefile? AFAIK, _FOR_TARGET will be used when running a compiler that generates code for the target platform, the others are used when running a native compiler. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9031-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 21:30:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29584 invoked by alias); 11 Aug 1999 21:30:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29560 invoked from network); 11 Aug 1999 21:30:42 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 11 Aug 1999 21:30:42 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id SAA14654; Wed, 11 Aug 1999 18:22:47 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id RAA15648; Wed, 11 Aug 1999 17:00:19 -0300 (EST) To: kostya@dsto.dp.ua Cc: gcc@gcc.gnu.org Subject: Re: About gcc under IRIX6.3 References: <35CEACAE.97645595@dsto.dp.ua> From: Alexandre Oliva Date: 11 Aug 1999 17:04:08 -0300 In-Reply-To: Nikonenko Konstantin's message of "Mon, 10 Aug 1998 11:17:50 +0300" Message-ID: Lines: 20 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 10, 1998, Nikonenko Konstantin wrote: > i install GNU gcc 2.6.3 (version number 1022867720) and > GNU binutils (version number 1022589620) > under IRIX 6.3 SGI R5000 mips and have next message: > ld: FATAL 9: I/O error (crt1.o): No such file or directory A friend of mine had the very same problem on a similar platform until he set GCC_EXEC_PREFIX appropriately. Anyway, gcc 2.6.3 is too old to be useful. The only reason to use it, other than *really* needing that particular version, is to build a newer gcc. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9032-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 21:35:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31929 invoked by alias); 11 Aug 1999 21:35:42 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31586 invoked from network); 11 Aug 1999 21:34:58 -0000 Received: from eising.k-net.dtu.dk (HELO eising.k-net.dk) (130.225.71.227) by egcs.cygnus.com with SMTP; 11 Aug 1999 21:34:58 -0000 Received: (qmail 17413 invoked from network); 11 Aug 1999 21:36:24 -0000 Received: from carlsberg.kampsax.dtu.dk (qmailr@192.38.212.2) by eising.k-net.dk with SMTP; 11 Aug 1999 21:36:24 -0000 Received: (qmail 27291 invoked from network); 11 Aug 1999 21:34:56 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by carlsberg.kampsax.dtu.dk with SMTP; 11 Aug 1999 21:34:56 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by k4315.kampsax.dtu.dk with SMTP; 11 Aug 1999 21:33:39 -0000 Date: 11 Aug 99 19:55:16 +0100 From: "Rask Ingemann Lambertsen" Subject: Re: Building cross, gcc reports error I don't see. To: "GCC mailing list" In-Reply-To: <37B05187.5C97E443@pentek.com> Message-ID: <942.892T830T11953950@kampsax.k-net.dk> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Organization: Me? Organised? Dream on... X-Files: The truth is out there. X-Mailer: THOR 2.5a (Amiga;TCP/IP) Den 10-Aug-99 17:21:27 skrev Charles Krug følgende om "Building cross, gcc reports error I don't see.": > m68k-wrs-vxworks/sys-include/sys/stat.h:43 parse error before > ULONG > What incredibly obvious thing have I overlooked here? > ->> ULONG st_dev; /* device ID number */ <<- Line 43 ^^^^^ That (as a result of a broken header file). When gcc says "parse error before xyz", don't take the "before" part too litteral. Often, the error is at, not before, xyz. Regards, /¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | | If it jams, force it. If it breaks, it needed replacing. | From gcc-return-9033-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 21:46:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2465 invoked by alias); 11 Aug 1999 21:46:44 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2449 invoked from network); 11 Aug 1999 21:46:39 -0000 Received: from smtprtp1.nortel.net (HELO smtprtp1.ntcom.nortel.net) (137.118.22.14) by egcs.cygnus.com with SMTP; 11 Aug 1999 21:46:39 -0000 Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Wed, 11 Aug 1999 17:46:23 -0400 Received: from zmtlde5a.ca.nortel.com ([47.64.13.90]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id P2BGWGNK; Wed, 11 Aug 1999 17:46:23 -0400 Received: from wmtl249c.nortel.ca (wmtl249c.ca.nortel.com [47.64.3.156]) by zmtlde5a.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PRPKXRDK; Wed, 11 Aug 1999 17:46:23 -0400 From: "Jerry Quinn" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14257.61228.968262.555393@gargle.gargle.HOWL> Date: Wed, 11 Aug 1999 17:46:20 -0400 (EDT) To: Jonathan Couper Cc: gcc Subject: PA-8500 vs. PA-8000 - gcc support? In-Reply-To: <001401bee43a$ab87ea80$2100a8c0@rincewind.g8labs.co.nz> References: <001401bee43a$ab87ea80$2100a8c0@rincewind.g8labs.co.nz> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) X-Orig: >> "Jonathan" == Jonathan Couper writes: Jonathan> Hiya We're using a PA-8000 machine, but are expecting to port to Jonathan> PA-8500 later in the year. I'm curious to know: Jonathan> - Does gcc have specific support for the 8500? No. We've added an optimization path for the 8000, but so far it's stuff that should be generically applicable to any 8x00. There's a few things. There is a machine model that attempts to capture retirement from the reorder buffers and a bit of floating point latency. There are patterns to generate multiply/accumulate instructions. We turn off the combined instructions such as fmpyadd since those can tie up the reorder buffers. And finally we turn off the 1.1 processor-specific cost adjustments. Jonathan> - Is there any significant difference between the two? According to public docs at HP, there are a few differences. First, the cache is on-chip, although I don't think that affects anything. Second, it has better branch prediction. The 8000 has to choose between static and dynamic prediction while the 8500 offers a combination of the two where dynamic prediction can compensate for bad static predictions. The 8500 (and 8200) also has a larger branch history table. The TLB is larger. And of course the clock rates are higher. I suspect that these changes probably don't mean any changes to the compiler although someone who actually knows their stuff may counter that. Jerry -- Jerry Quinn Tel: (514) 761-8737 jquinn@nortelnetworks.com Fax: (514) 761-8505 Speech Recognition Research From gcc-return-9034-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 22:46:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7251 invoked by alias); 11 Aug 1999 22:46:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7224 invoked from network); 11 Aug 1999 22:46:41 -0000 Received: from law2-f146.hotmail.com (HELO hotmail.com) (216.32.181.146) by egcs.cygnus.com with SMTP; 11 Aug 1999 22:46:41 -0000 Received: (qmail 34581 invoked by uid 0); 11 Aug 1999 22:42:09 -0000 Message-ID: <19990811224209.34580.qmail@hotmail.com> Received: from 199.186.192.254 by www.hotmail.com with HTTP; Wed, 11 Aug 1999 15:42:09 PDT X-Originating-IP: [199.186.192.254] From: "John Carson" To: gcc@gcc.gnu.org Subject: Built & installed GCC Date: Wed, 11 Aug 1999 15:42:09 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed #!/bin/sh # This file was generated automatically by configure. Do not edit. # This directory was configured as follows: //f/gcc-2.95/configure --with-gcc-version-trigger=//f/gcc-2.95/gcc/version.c --host=i586-pc-cygwin32 --norecursion # using "mh-frag" _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From gcc-return-9035-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 11 23:59:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12654 invoked by alias); 11 Aug 1999 23:59:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12639 invoked from network); 11 Aug 1999 23:59:16 -0000 Received: from mahler.princeton.edu (128.112.80.40) by egcs.cygnus.com with SMTP; 11 Aug 1999 23:59:16 -0000 Received: (from tim@localhost) by mahler.Princeton.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) id TAA81305; Wed, 11 Aug 1999 19:57:52 -0400 (EDT) From: tim@mahler.Princeton.EDU (Tim Hollebeek) Message-Id: <199908112357.TAA81305@mahler.Princeton.EDU> Subject: Re: About gcc under IRIX6.3 To: oliva@dcc.unicamp.br (Alexandre Oliva) Date: Wed, 11 Aug 1999 19:57:52 -0400 (EDT) Cc: kostya@dsto.dp.ua, gcc@gcc.gnu.org In-Reply-To: from "Alexandre Oliva" at Aug 11, 99 05:04:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Alexandre Oliva writes ... > > On Aug 10, 1998, Nikonenko Konstantin wrote: > > > i install GNU gcc 2.6.3 (version number 1022867720) and > > GNU binutils (version number 1022589620) > > under IRIX 6.3 SGI R5000 mips and have next message: > > > ld: FATAL 9: I/O error (crt1.o): No such file or directory > > A friend of mine had the very same problem on a similar platform until > he set GCC_EXEC_PREFIX appropriately. > > Anyway, gcc 2.6.3 is too old to be useful. The only reason to use it, > other than *really* needing that particular version, is to build a > newer gcc. Another reason not to use it: gcc 2.6.3 *predates* IRIX 6.3, so it would be silly to expect 2.6.3 to support IRIX 6.3 :) -Tim From gcc-return-9036-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 03:46:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28233 invoked by alias); 12 Aug 1999 03:46:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28200 invoked from network); 12 Aug 1999 03:46:55 -0000 Received: from mescaline.gnu.org (158.121.106.21) by egcs.cygnus.com with SMTP; 12 Aug 1999 03:46:55 -0000 Received: from mmpp5.csie.ncku.edu.tw (mmpp5.iie.ncku.edu.tw [140.116.46.128]) by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id XAA02355 for ; Wed, 11 Aug 1999 23:46:21 -0400 From: pschen@mmpp5.csie.ncku.edu.tw Received: (from pschen@localhost) by mmpp5.csie.ncku.edu.tw (8.8.7/8.8.7) id LAA21512 for gcc@gcc.gnu.org; Thu, 12 Aug 1999 11:25:27 +0800 Message-Id: <199908120325.LAA21512@mmpp5.csie.ncku.edu.tw> Subject: subscribe crossgcc pschen@mmpp5.iie.ncku.edu.tw To: gcc@gcc.gnu.org Date: Thu, 12 Aug 1999 11:25:27 +0800 (CST) Content-Type: text subscribe crossgcc pschen@mmpp5.iie.ncku.edu.tw From gcc-return-9037-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 04:49:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1465 invoked by alias); 12 Aug 1999 04:49:06 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1450 invoked from network); 12 Aug 1999 04:49:04 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 12 Aug 1999 04:49:04 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id VAA18465; Wed, 11 Aug 1999 21:49:04 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id VAA14702; Wed, 11 Aug 1999 21:49:04 -0700 Date: Wed, 11 Aug 1999 21:49:04 -0700 From: Richard Henderson To: Zack Weinberg Cc: law@cygnus.com, John Wehle , gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Message-ID: <19990811214904.B14692@cygnus.com> References: <199908111829.LAA04319@zack.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199908111829.LAA04319@zack.bitmover.com>; from Zack Weinberg on Wed, Aug 11, 1999 at 11:29:24AM -0700 On Wed, Aug 11, 1999 at 11:29:24AM -0700, Zack Weinberg wrote: > At RTL generation time, pretend that there are no HImode operations > other than load/store. This loses. I'm not sure of The Cause, if in fact there is a single cause, but the overall effect was clear. You can easily test this out for yourself by defining PROMOTE_MODE. > For example, we'd produce > > (set (reg:SI 21) (extend:SI (mem:HI address))) > (set (reg:SI 22) (add (reg:SI 21) (const_int 1))) > (set (mem:HI address) (subreg:HI (reg:SI 22) 0)) > > for an increment of a HImode memory location. As opposed to `incw (%eax)'? Unfriendly. > After reload, we decide how to generate the load-and-extends based > on processor type (xor/movw versus movzwl, etc.) Yes. You can also find places where an extra xor would be helpful to prevent stalls between unrelated uses of a register. r~ From gcc-return-9038-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 08:00:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15434 invoked by alias); 12 Aug 1999 08:00:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15419 invoked from network); 12 Aug 1999 08:00:28 -0000 Received: from rtl.cygnus.com (HELO gluttony.geoffk.wattle.id.au) (205.180.230.21) by egcs.cygnus.com with SMTP; 12 Aug 1999 08:00:28 -0000 Received: (from geoffk@localhost) by gluttony.geoffk.wattle.id.au (8.9.3/8.9.3) id RAA00839; Thu, 12 Aug 1999 17:34:29 +1000 Date: Thu, 12 Aug 1999 17:34:29 +1000 Message-Id: <199908120734.RAA00839@gluttony.geoffk.wattle.id.au> From: Geoff Keating To: egcs@gcc.gnu.org Subject: Random C9X conformance notes Here are some things that also need to be looked at for C9X conformance: > Standard Libraries > ================== > > GCC by itself attempts to be what the ISO/ANSI C standard calls a > "conforming freestanding implementation". This means all ANSI C > language features are available, as well as the contents of `float.h', > `limits.h', `stdarg.h', and `stddef.h'. ... In C9X, there are also iso646.h, stdbool.h, and stdint.h, of which gcc does provide the first two. There seems to be no particular reason why gcc shouldn't provide stdint.h also. In fact, since it's compiler-specific, it would probably be a good idea to override the system's one; you don't want intmax_t referring to some type longer than (this version of) gcc supports. > * `-2147483648' is positive. > > This is because 2147483648 cannot fit in the type `int', so > (following the ANSI C rules) its data type is `unsigned long int'. > Negating this value yields 2147483648 again. In C9X, -2147483648 is negative, because 2147483648 has type 'long long'. -0x80000000 is still positive. -2147483648u is also still positive. If ANSI C really required this before, then this is a significant quiet change and may go away before the final standard (I'm looking at last August's draft). It may not. The draft does make it very clear that decimal constants are always signed. -- Geoffrey Keating From gcc-return-9039-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 08:47:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18215 invoked by alias); 12 Aug 1999 08:47:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18200 invoked from network); 12 Aug 1999 08:47:21 -0000 Received: from mumrik.nada.kth.se (130.237.226.10) by egcs.cygnus.com with SMTP; 12 Aug 1999 08:47:20 -0000 Received: from localhost (d92-foh@localhost) by mumrik.nada.kth.se (8.8.7/8.8.7) with SMTP id KAA21355; Thu, 12 Aug 1999 10:47:05 +0200 (MET DST) Date: Thu, 12 Aug 1999 10:47:05 +0200 (MET DST) From: =?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?= Reply-To: =?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?= To: Mark Mitchell cc: gcc@gcc.gnu.org Subject: Re: PATCH to remove signature support In-Reply-To: <19990811132743V.mitchell@codesourcery.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 11 Aug 1999, Mark Mitchell wrote: > This patch removes support for `signature', a g++ extension that is > little-used and which Jason and I agreed should go. The reduction in > complexity elsewhere in the front-end will be a big win. Signatures fills a similar role as interfaces in Java, but are more advanced. A signature is in fact compiler support for the bridge pattern. Now, this IS useful when building distributed objects. You can bind the signatures to either an implementation or a proxy and with the help of signatures the inheritance hierarchy can be different in both cases. I also like signatures because they streamline the design of an interface. Anyway, I was trying to add inheritance to signatures, but I can just as well stop that work now... :-) So now I have a question about efficiency: It seems to me that virtual abstract base classes is needed if you want to separate the implementation classes from the interfaces without the help of signatures. struct AlfaInterface { virtual int a () = 0; }; struct BetaInterface : public virtual AlfaInterface { virtual int b () = 0; }; struct AlfaImpl : public virtual AlfaInterface { int a () { return 0; } }; struct BetaImpl : public virtual BetaInterface, public AlfaImpl { int q; BetaImpl (int a) : q(a) {} int b () { return q; } }; int main () { BetaInterface *b = new BetaImpl(2); return b->b(); } What is the efficiency of the code when using empty abstract virtual base classes? I looked at the assembler output and it seems have its share of thunks. Is it possible to make the vtable smarter since there is no data in the interfaces? I can understand that not many people uses signatures since it is gcc extension, but is there nothing in upcoming C++ standards that sort of resembles interfaces or signatures? //Fredrik From gcc-return-9040-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 08:58:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19246 invoked by alias); 12 Aug 1999 08:58:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19231 invoked from network); 12 Aug 1999 08:58:02 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 12 Aug 1999 08:58:02 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id CAA11118; Thu, 12 Aug 1999 02:54:57 -0600 X-Mailer: exmh version 2.0.2 To: Mark Klein cc: gcc@gcc.gnu.org Subject: Re: muldi3, divdi3 and remdi3 patterns Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 11 Aug 1999 07:55:30 PDT. <4.1.19990811073640.00ce36f0@garfield.dis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Aug 1999 02:54:56 -0600 Message-ID: <11115.934448096@upchuck.cygnus.com> From: Jeffrey A Law In message <4.1.19990811073640.00ce36f0@garfield.dis.com>you write: > case UDIV: > case MOD: > case UMOD: > return COSTS_N_INSNS (60); > > Did you base the costs on anything concrete such as number of cycles > or instructions per operation, or are these arbitrary values that > simply indicate the relative costs? What does the "60" represent? I don't remember. It's been many many years since I even looked at those cost macros. Basically they're supposed to provide rough estimates of the number of instructions/cycles necessary to implement each operation (on average). Whether or not the PA mul/div stuff follows that convention I'm not sure (again, it's been a very very long time). jeff From gcc-return-9041-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 09:56:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24610 invoked by alias); 12 Aug 1999 09:55:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24594 invoked from network); 12 Aug 1999 09:55:41 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 12 Aug 1999 09:55:41 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id LAA15173; Thu, 12 Aug 1999 11:50:34 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id LAA04682; Thu, 12 Aug 1999 11:50:09 +0200 Date: Thu, 12 Aug 1999 11:50:09 +0200 Message-Id: <199908120950.LAA04682@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: d92-foh@nada.kth.se CC: mark@codesourcery.com, gcc@gcc.gnu.org In-reply-to: (message from Fredrik =?ISO-8859-1?Q?=D6hrstr=F6m?= on Thu, 12 Aug 1999 10:47:05 +0200 (MET DST)) Subject: Re: PATCH to remove signature support References: User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > Signatures fills a similar role as interfaces in Java, but are more > advanced. A signature is in fact compiler support for the bridge > pattern. Now, this IS useful when building distributed objects. You > can bind the signatures to either an implementation or a proxy and > with the help of signatures the inheritance hierarchy can be > different in both cases. I think this is not the question. The reasons you mention are exactly those which originally lead to the introduction of signatures. The question is: Does anybody actually *use* signatures, in a real application (rather then just a demonstration what they are good for). I doubt that anybody would use it in a real application that also needs to be portable - nobody else but g++ supports it. > It seems to me that virtual abstract base classes is needed if you > want to separate the implementation classes from the interfaces > without the help of signatures. Yes, this is the common idiom. > What is the efficiency of the code when using empty abstract virtual > base classes? I looked at the assembler output and it seems have its > share of thunks. Compared to signatures, it is way more efficient. In your example, with -fno-exceptions, on i586-pc-linux-gnu, you get about 6 instructions for a virtual call (plus 2 for the thunk), whereas you need more than 20 for a signature call. > Is it possible to make the vtable smarter since there is no data in > the interfaces? Yes. Virtual bases suffer two problems: the vbase pointer isn't really needed (could be a vtable entry), and vbase class itself could overlay with some other part of the object, if that has a vtable that is an extension of the virtual base' vtable. > I can understand that not many people uses signatures since it is > gcc extension, but is there nothing in upcoming C++ standards that > sort of resembles interfaces or signatures? Well, I think virtual bases are good enough. They are used to implement interfaces all the time (e.g. see CORBA), so let's concentrate on improving the implementation for vbases instead of enhancing an unused feature. Regards, Martin From gcc-return-9042-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 14:18:40 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4688 invoked by alias); 12 Aug 1999 14:18:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4673 invoked from network); 12 Aug 1999 14:18:36 -0000 Received: from gov-1-47.gov.nf.ca (HELO MAIL.GOV.NF.CA) (209.128.28.47) by egcs.cygnus.com with SMTP; 12 Aug 1999 14:18:36 -0000 Received: from GOV_NF_PRIMARY-Message_Server by MAIL.GOV.NF.CA with Novell_GroupWise; Thu, 12 Aug 1999 11:58:56 -0230 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 12 Aug 1999 11:49:15 -0230 From: "Jason Pond" To: Subject: Installing gcc 2.95 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have just recently downloaded the latest and greatest GCC-2.95 but I am = having some difficulty installing it. I find the installation instructions= a bit confusing....I am by no means an expert in system administration so = that is likely the major problem. I am trying to install the compiler on = a SUN ULTRA-2 with solaris 2.6 OS. However, when I try and configure, the = scripts fail and I can't seem to figure out why. I think that it may have = something to do with the path settings for either cc or gcc as specified = in the install instructions or the setting of CC. The following is the error message I receive after issuing this command ../gcc-2.95/configure --prefix=3D/usr1/gcc_tools Configuring for a sparc-sun-solaris2.6 host. Created "Makefile" in /usr1/gcc using "mh-frag" /usr/ucb/cc: language optional software package not installed *** The command '/usr/ucb/cc -o conftest -g conftest.c' failed. *** You must set the environment variable CC to a working compiler. >From what I can read from this message, I need a compiler in order to = install the compiler??? However, I don't have a compiler.....thats the = reason I am installing it. Maybe I need a different download??=20 Does anyone have any ideas, or a more detailed installation procedure. Thanks Jason Pond Jason Pond Ecosystem Health Division Dept. of Forest Resources and Agrifoods Corner Brook, Nfld A2H 6J8 709-637-2507 (Tel) 709-637-2290 (Fax) Join the Global Association of Online Foresters - www.foresters.org From gcc-return-9043-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 14:55:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11687 invoked by alias); 12 Aug 1999 14:55:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11672 invoked from network); 12 Aug 1999 14:55:01 -0000 Received: from qnx.com (209.226.137.1) by egcs.cygnus.com with SMTP; 12 Aug 1999 14:55:01 -0000 Received: (from alain@localhost) by qnx.com (8.8.8/8.8.8) id KAA28132 for gcc@gcc.gnu.org; Thu, 12 Aug 1999 10:51:30 -0400 Message-Id: <199908121451.KAA28132@qnx.com> Subject: Re: Installing gcc 2.95 To: jpond@mail.gov.nf.ca (Jason Pond) Date: Thu, 12 Aug 1999 10:51:17 -0400 (EDT) From: "Alain Magloire" Cc: gcc@gcc.gnu.org In-Reply-To: from "Jason Pond" at Aug 12, 1999 11:49:15 AM X-Mailer: ELM [version 2.5 PL0b1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bonjour > ../gcc-2.95/configure --prefix=3D/usr1/gcc_tools > > Configuring for a sparc-sun-solaris2.6 host. > Created "Makefile" in /usr1/gcc using "mh-frag" > /usr/ucb/cc: language optional software package not installed > *** The command '/usr/ucb/cc -o conftest -g conftest.c' failed. > *** You must set the environment variable CC to a working compiler. > > >From what I can read from this message, I need a compiler in order to = > install the compiler??? However, I don't have a compiler.....thats the = > reason I am installing it. Maybe I need a different download??=20 > You could try to bootstrap/install with the binaries from sunsite http://sunsite.unc.edu/pub/packages/solaris Bye, -- au revoir, alain ---- Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!! From gcc-return-9044-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 14:56:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12210 invoked by alias); 12 Aug 1999 14:56:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12181 invoked from network); 12 Aug 1999 14:56:17 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 12 Aug 1999 14:56:17 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id HAA13913; Thu, 12 Aug 1999 07:53:42 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id HAA29258; Thu, 12 Aug 1999 07:53:41 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id HAA05929; Thu, 12 Aug 1999 07:53:41 -0700 Message-Id: <199908121453.HAA05929@atrus.synopsys.com> Subject: Re: PATCH to remove signature support To: martin@mira.isdn.cs.tu-berlin.de (Martin v. Loewis) Date: Thu, 12 Aug 99 7:53:40 PDT Cc: d92-foh@nada.kth.se, mark@codesourcery.com, gcc@gcc.gnu.org In-Reply-To: <199908120950.LAA04682@mira.isdn.cs.tu-berlin.de>; from "Martin v. Loewis" at Aug 12, 99 11:50 am X-Mailer: ELM [version 2.3 PL11] > The question is: Does anybody actually *use* signatures, in a real > application (rather then just a demonstration what they are good for). I suspect that many people are in a position like mine, and must write code that is accepted by more than one compiler (possibly with #ifdefs). This pretty much rules out use of non-standard features. > > I can understand that not many people uses signatures since it is > > gcc extension, but is there nothing in upcoming C++ standards that > > sort of resembles interfaces or signatures? The standard is out and frozen. Eventually there will be a new revision, but all that the committee is doing now is wrapping up loose ends (issuing "defect reports", which are minor corrections to errors in the standard). In any case, a Java interface is simply a restricted form of multiple inheritance: it is a lot like C++ virtual base classes but the restriction that interfaces have no data members gets rid of the ugliness with constructors that C++ users run into when they use virtual bases. From gcc-return-9045-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 15:38:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18508 invoked by alias); 12 Aug 1999 15:38:15 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18488 invoked from network); 12 Aug 1999 15:38:02 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 12 Aug 1999 15:38:02 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id MAA29010; Thu, 12 Aug 1999 12:30:54 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id MAA15893; Thu, 12 Aug 1999 12:30:54 -0300 (EST) To: tim@mahler.Princeton.EDU (Tim Hollebeek) Cc: kostya@dsto.dp.ua, gcc@gcc.gnu.org Subject: Re: About gcc under IRIX6.3 References: <199908112357.TAA81305@mahler.Princeton.EDU> From: Alexandre Oliva Date: 12 Aug 1999 12:34:49 -0300 In-Reply-To: tim@mahler.Princeton.EDU's message of "Wed, 11 Aug 1999 19:57:52 -0400 (EDT)" Message-ID: Lines: 14 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 11, 1999, tim@mahler.Princeton.EDU (Tim Hollebeek) wrote: > Another reason not to use it: gcc 2.6.3 *predates* IRIX 6.3, so it > would be silly to expect 2.6.3 to support IRIX 6.3 :) AFAIK, SGI has ported it to IRIX 6.3 and distributes it in a CD. But I may be wrong; it may just be a build for IRIX 5 that happens to work on IRIX 6. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9046-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 16:53:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31569 invoked by alias); 12 Aug 1999 16:53:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31553 invoked from network); 12 Aug 1999 16:53:40 -0000 Received: from gw.varesearch.com (HELO oxygen.su.varesearch.com) (@209.81.8.2) by egcs.cygnus.com with SMTP; 12 Aug 1999 16:53:40 -0000 Received: from hydrogen.su.varesearch.com ([10.1.0.1] helo=varesearch.com) by oxygen.su.varesearch.com with esmtp (Exim 2.12 #6) id 11Ey6k-0003eC-00 for egcs@egcs.cygnus.com; Thu, 12 Aug 1999 09:53:38 -0700 Received: by varesearch.com (Postfix, from userid 561) id C8A8F3FC1; Thu, 12 Aug 1999 09:53:38 -0700 (PDT) Subject: Cross compile for g77 and objc To: egcs@egcs.cygnus.com Date: Thu, 12 Aug 1999 09:53:38 -0700 (PDT) X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990812165338.C8A8F3FC1@varesearch.com> From: hjl@varesearch.com (H.J. Lu) I saw cross compile disabled for g77 and objc. I enabled it by hand. It seems to work for me from glibc 2 to libc 5 on x86. I also tried from glibc 2/x86 to glibc 2/ppc. -- H.J. Lu (hjl@gnu.org) From gcc-return-9047-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 17:34:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3860 invoked by alias); 12 Aug 1999 17:34:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3842 invoked from network); 12 Aug 1999 17:34:37 -0000 Received: from mescaline.gnu.org (158.121.106.21) by egcs.cygnus.com with SMTP; 12 Aug 1999 17:34:37 -0000 Received: from pasanda.cygnus.co.uk (dns.cygnus.co.uk [194.130.39.3]) by mescaline.gnu.org (8.9.1a/8.9.1) with SMTP id NAA18677 for ; Thu, 12 Aug 1999 13:34:30 -0400 Received: (qmail 4245 invoked by alias); 12 Aug 1999 17:33:20 -0000 Received: (qmail 4240 invoked from network); 12 Aug 1999 17:33:19 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 12 Aug 1999 17:33:19 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id SAA22337; Thu, 12 Aug 1999 18:32:10 +0100 From: Joern Rennecke Message-Id: <199908121732.SAA22337@phal.cygnus.co.uk> Subject: Re: muldi3, divdi3 and remdi3 patterns In-Reply-To: <11115.934448096@upchuck.cygnus.com> from Jeffrey A Law at "Aug 12, 1999 2:54:56 am" To: law@cygnus.com Date: Thu, 12 Aug 1999 18:32:10 +0100 (BST) Cc: mklein@dis.com, gcc@gcc.gnu.org X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit There is also the issue that the distributive law doesn't apply to COSTS_N_INSNS and +, i.e COSTS_N_INSNS (n) + COSTS_N_INSNS (m) < COSTS_N_INSNS (n+m) From gcc-return-9048-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 17:40:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4822 invoked by alias); 12 Aug 1999 17:40:09 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4807 invoked from network); 12 Aug 1999 17:40:03 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 12 Aug 1999 17:40:03 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id KAA26395; Thu, 12 Aug 1999 10:39:32 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id KAA00030; Thu, 12 Aug 1999 10:39:31 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id KAA07878; Thu, 12 Aug 1999 10:39:31 -0700 Message-Id: <199908121739.KAA07878@atrus.synopsys.com> Subject: Re: Random C9X conformance notes To: geoffk@ozemail.com.au (Geoff Keating) Date: Thu, 12 Aug 99 10:39:30 PDT Cc: egcs@gcc.gnu.org In-Reply-To: <199908120734.RAA00839@gluttony.geoffk.wattle.id.au>; from "Geoff Keating" at Aug 12, 99 5:34 pm X-Mailer: ELM [version 2.3 PL11] Geoff Keating quotes the gcc manual: > > * `-2147483648' is positive. > > > > This is because 2147483648 cannot fit in the type `int', so > > (following the ANSI C rules) its data type is `unsigned long int'. > > Negating this value yields 2147483648 again. The manual is incorrect. It should read * `-2147483648' is positive for ports where `long' is 32 bits. On the Alpha, it is negative. In the early days, gcc had the 'all the world's a Vax' disease, so this statement was true without qualification. Geoff again: > If ANSI C really required this before, then this is a significant > quiet change and may go away before the final standard (I'm looking at > last August's draft). It may not. The draft does make it very clear > that decimal constants are always signed. I don't see how C9X could drop this change. If long long is a true type that is co-equal with other types, they have to do it this way. In ANSI (ISO) C, if an integral constant doesn't fit in an int, we first see if it fits in a long, and finally try unsigned long. In C9X, we try int, long, and finally long long. This follows naturally if you say that long long is a real type (though one could add unsigned long long as a final type, it's arguably more natural to ask the user to give a U to get an unsigned literal). One could argue that since GNU C supports long long, it should have been using the C9X semantics all along. The change is less significant than it appears, because it's hard to write programs that don't use 'long long' where you can observe the difference. That is, if you use -2147483648 to initialize a 32-bit value, you will get the same result for ANSI and C9X. One possibility is for gcc to issue warnings for integral constants (that have no U or LL qualifier) that don't fit in a long, but that do fit in an unsigned long, since those are the constants that behave differently in ANSI and C9X, and even in ANSI may have surprising results. The user can always eliminate the warning by adding an explicit U or LL. From gcc-return-9049-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 18:25:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10463 invoked by alias); 12 Aug 1999 18:25:16 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10447 invoked from network); 12 Aug 1999 18:25:10 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 12 Aug 1999 18:25:10 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id MAA12311; Thu, 12 Aug 1999 12:22:00 -0600 X-Mailer: exmh version 2.0.2 To: hjl@varesearch.com (H.J. Lu) cc: egcs@egcs.cygnus.com Subject: Re: Cross compile for g77 and objc Reply-To: law@cygnus.com In-reply-to: Your message of Thu, 12 Aug 1999 09:53:38 PDT. <19990812165338.C8A8F3FC1@varesearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Aug 1999 12:22:00 -0600 Message-ID: <12308.934482120@upchuck.cygnus.com> From: Jeffrey A Law In message <19990812165338.C8A8F3FC1@varesearch.com>you write: > I saw cross compile disabled for g77 and objc. I enabled it by hand. > It seems to work for me from glibc 2 to libc 5 on x86. I also tried > from glibc 2/x86 to glibc 2/ppc. ?!? What are you talking about? Did you actually read the instructions we provide for building cross compilers? "make cross" is not the way to build cross compilers anymore. THe target should be removed from the toplevel Makefile. jeff From gcc-return-9050-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 19:02:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14404 invoked by alias); 12 Aug 1999 19:02:05 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14389 invoked from network); 12 Aug 1999 19:02:03 -0000 Received: from caip.rutgers.edu (128.6.236.10) by egcs.cygnus.com with SMTP; 12 Aug 1999 19:02:03 -0000 Received: (from ghazi@localhost) by caip.rutgers.edu (8.9.3/8.9.3) id PAA29751 for egcs@egcs.cygnus.com; Thu, 12 Aug 1999 15:02:02 -0400 (EDT) Date: Thu, 12 Aug 1999 15:02:02 -0400 (EDT) From: "Kaveh R. Ghazi" Message-Id: <199908121902.PAA29751@caip.rutgers.edu> To: egcs@egcs.cygnus.com Subject: What should -Wmissing-noreturn do with "int main(){exit(0);}" ? The flag -Wmissing-noreturn produces a warning when given code like this: > int main() { exit(0); } foo.c: In function `main': foo.c:1: warning: function might be possible candidate for attribute `noreturn' The diagnostic is technically correct, but perhaps it should do something different here. I see two alternatives. 1. Ignore function `main' for the purpose of the noreturn warning. 2. When function main is noreturn, change the warning to suggest changing `exit(0)' to `return 0' in function `main'. I lean towards doing #1. Comments? --Kaveh -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions From gcc-return-9051-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 19:11:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18071 invoked by alias); 12 Aug 1999 19:11:23 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18056 invoked from network); 12 Aug 1999 19:11:21 -0000 Received: from smtp.ucla.edu (HELO serval.noc.ucla.edu) (169.232.10.57) by egcs.cygnus.com with SMTP; 12 Aug 1999 19:11:21 -0000 Received: from cs.ucla.edu (ts52-1.wla.ts.ucla.edu [164.67.25.30]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id MAA11753; Thu, 12 Aug 1999 12:11:15 -0700 (PDT) Message-ID: <37B31D07.1FF6EBE1@cs.ucla.edu> Date: Thu, 12 Aug 1999 12:14:15 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: order of switches Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It appears that the order of switches that I give to g++ is critical to how it works. It may silently ignore -I or -l if they aren't in the correct place. That seems weird and causes problems, e.g., [imarkov@localhost Ctainers1.8]$ make-gnu g++ -g -DABKDEBUG -fPIC -fno-for-scope -Wall -pedantic -pipe -I -I/home/userg/code/OUR/symlinks/ABKCommon -I. -c bitBoard.cxx In file included from bitBoard.cxx:19: bitBoard.h:27: abkassert.h: No such file or directory bitBoard.h:28: abkio.h: No such file or directory ^C make: *** wait: No child processes. Stop. make: *** Waiting for unfinished jobs.... make: *** wait: No child processes. Stop. [imarkov@localhost Ctainers1.8]$ g++ -I/home/userg/code/OUR/symlinks/ABKCommon -I. -c rbtree.cxx [imarkov@localhost Ctainers1.8]$ I just grep'ed man g++ for "order" and it there were no matches. Any pointers/comments? thanks, Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-9052-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 19:41:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21395 invoked by alias); 12 Aug 1999 19:41:44 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21380 invoked from network); 12 Aug 1999 19:41:36 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 12 Aug 1999 19:41:36 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.8.7/8.8.7) with ESMTP id MAA04403 for ; Thu, 12 Aug 1999 12:45:30 -0700 To: gcc@gcc.gnu.org Subject: make_node vs. copy_node X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990812124530G.mitchell@codesourcery.com> Date: Thu, 12 Aug 1999 12:45:30 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 27 These two functions do not operate in the same way with respect to obstacks. In particular, make_node does things like this: /* All decls in an inline function need to be saved. */ if (obstack != &permanent_obstack) obstack = saveable_obstack; whereas copy_node just blithely allocated on the current_obstack. This has bad consequences if one does a copy_node on a decl in an inline function. (Why would one do this? When instantiating a template, for example; we copy the template decl and then modify it.) I think that the semantics of copy_node should be roughly: new_node = make_node (code); memcpy (new_node, old_node, size); Does anyone disagree? (I don't propose literally doing this; the example is only for clarity.) Does anyone care to pre-approve a patch that replicates the obstack handling of make_node, assuming the regression tests don't blow up? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-9053-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 20:11:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24667 invoked by alias); 12 Aug 1999 20:11:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24652 invoked from network); 12 Aug 1999 20:11:54 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 12 Aug 1999 20:11:54 -0000 Received: from marathon.synopsys.com (marathon.synopsys.com [146.225.100.41]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id NAA08039; Thu, 12 Aug 1999 13:10:56 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by marathon.synopsys.com (8.8.8/8.8.8) with SMTP id NAA08631; Thu, 12 Aug 1999 13:10:56 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id NAA11553; Thu, 12 Aug 1999 13:10:55 -0700 Message-Id: <199908122010.NAA11553@atrus.synopsys.com> Subject: Re: order of switches To: imarkov@cs.ucla.edu (Igor Markov) Date: Thu, 12 Aug 99 13:10:55 PDT Cc: gcc@gcc.gnu.org In-Reply-To: <37B31D07.1FF6EBE1@cs.ucla.edu>; from "Igor Markov" at Aug 12, 99 12:14 pm X-Mailer: ELM [version 2.3 PL11] > It appears that the order of switches that I give to g++ > is critical to how it works. It may silently ignore -I or -l > if they aren't in the correct place. That seems weird and > causes problems, e.g., This is a beginner question. gcc's behavior is the same as that of all Unix C compilers: the order of the switches most definitely matters for include file directories and libraries. You are specifying the order in which include directory paths and libraries are searched. Libraries are only searched for symbols that are undefined at a particular point. Similarly, for headers, the order of -I switches affects handling of recursive includes. > I just grep'ed man g++ for "order" and it there were no matches. The man pages are very minimal guides to the option flags. The real documentation of GCC is in the texinfo files. From gcc-return-9054-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 20:13:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25524 invoked by alias); 12 Aug 1999 20:13:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25509 invoked from network); 12 Aug 1999 20:13:28 -0000 Received: from law2-oe17.hotmail.com (HELO hotmail.com) (216.32.180.121) by egcs.cygnus.com with SMTP; 12 Aug 1999 20:13:28 -0000 Received: (qmail 5189 invoked by uid 65534); 12 Aug 1999 20:13:02 -0000 Message-ID: <19990812201302.5188.qmail@hotmail.com> X-Originating-IP: [171.78.42.210] From: "Chris Griffin" To: Subject: debugging code compiled with gcc 2.95 Date: Thu, 12 Aug 1999 16:11:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Hi, I am wondering what the proper debugging tool is for gcc 2.95. I've tried using gdb 4.16 and 4.18, and I'm having problems with both of them. Every time I try to print an object, I get a debugger segmentation fault. Thanks for any info! Chris From gcc-return-9055-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 20:23:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26752 invoked by alias); 12 Aug 1999 20:23:44 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26737 invoked from network); 12 Aug 1999 20:23:39 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 12 Aug 1999 20:23:39 -0000 Received: from cs.ucla.edu (ts52-1.wla.ts.ucla.edu [164.67.25.30]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id NAA18708; Thu, 12 Aug 1999 13:23:34 -0700 (PDT) Message-ID: <37B32DFB.DA4D6BBB@cs.ucla.edu> Date: Thu, 12 Aug 1999 13:26:35 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Joe Buck CC: gcc@gcc.gnu.org Subject: Re: order of switches References: <199908122010.NAA11553@atrus.synopsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joe Buck wrote: > > > It appears that the order of switches that I give to g++ > > is critical to how it works. It may silently ignore -I or -l > > if they aren't in the correct place. That seems weird and > > causes problems, e.g., > > This is a beginner question. > > gcc's behavior is the same as that of all Unix C compilers: well... thank you very much, but I've been working with SunCC for 3+ years, am now porting to g++ and having problems (which is why the question arose) > the order of the switches most definitely matters for include file > directories and libraries. yes, that relates to the order, but that *does* seem trivial (esp. that I am using the Makefiles which work with SunCC) In one instance I had to move -l after the .o file so that gcc does not silently ignore -l In another instance I was bitten by both -Ixxx and -I being legal (I defined STL="" because g++ has a good STL inside) oh, well... it looks people like reading 50% of email and shoot a reply immediately. That's rarely useful. > > I just grep'ed man g++ for "order" and it there were no matches. > > The man pages are very minimal guides to the option flags. The real > documentation of GCC is in the texinfo files. I get an impression of that this is some kind of conspiracy (gee !) .. not sure, but, perhaps, to cause people to buy support ? (yes, I understand one can look at this from difft angles ... but once I have my angle, it may be difficult to convince me otherwise) Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-9056-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 20:27:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27765 invoked by alias); 12 Aug 1999 20:27:53 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27750 invoked from network); 12 Aug 1999 20:27:51 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 12 Aug 1999 20:27:51 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id NAA24484; Thu, 12 Aug 1999 13:20:03 -0700 Message-Id: <199908122020.NAA24484@zack.bitmover.com> To: Richard Henderson cc: Zack Weinberg , law@cygnus.com, John Wehle , gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic In-Reply-To: Message from Richard Henderson of "Wed, 11 Aug 1999 21:49:04 PDT." <19990811214904.B14692@cygnus.com> Date: Thu, 12 Aug 1999 13:20:03 -0700 From: Zack Weinberg Richard Henderson wrote: > On Wed, Aug 11, 1999 at 11:29:24AM -0700, Zack Weinberg wrote: > > At RTL generation time, pretend that there are no HImode operations > > other than load/store. > > This loses. I'm not sure of The Cause, if in fact there is a single > cause, but the overall effect was clear. > > You can easily test this out for yourself by defining PROMOTE_MODE. I did. One problem leaps out at me: PROMOTE_MODE does math in HImode and fixes up the registers afterward - for example: (insn 37 34 38 (parallel[ (set (reg:HI 31) (plus:HI (subreg/s/u:HI (reg/v:SI 26) 0) (subreg:HI (reg/v:SI 29) 0))) (clobber (reg:CC 17 flags)) ] ) -1 (nil) (nil)) (insn 38 37 40 (parallel[ (set (reg:SI 32) (zero_extend:SI (reg:HI 31))) (clobber (reg:CC 17 flags)) ] ) -1 (nil) (nil)) which eventually winds up being addw %dx, %ax # 37 *addhi_1/1 [length = 3] movzwl %ax, %eax # 40 zero_extendhisi2/1 [length = 3] in the middle of a loop. (Same test case as last time, PROMOTE_MODE copied from i386/os2.h.) What we actually want is to do everything in SImode until the results become visible outside a function - returning, or write to memory. > > For example, we'd produce > > > > (set (reg:SI 21) (extend:SI (mem:HI address))) > > (set (reg:SI 22) (add (reg:SI 21) (const_int 1))) > > (set (mem:HI address) (subreg:HI (reg:SI 22) 0)) > > > > for an increment of a HImode memory location. > > As opposed to `incw (%eax)'? Unfriendly. I thought that inc MEM was discouraged on post-486. zw From gcc-return-9057-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 20:46:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30467 invoked by alias); 12 Aug 1999 20:46: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30449 invoked from network); 12 Aug 1999 20:46:47 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 12 Aug 1999 20:46:47 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.8.7/8.8.7) with ESMTP id NAA13210 for ; Thu, 12 Aug 1999 13:50:43 -0700 To: gcc@gcc.gnu.org Subject: copy_node, again X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990812135043K.mitchell@codesourcery.com> Date: Thu, 12 Aug 1999 13:50:43 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 10 Well, it looks like some parts of the compiler use copy_node *specifically* to move data from one obstack to another. So, consider my suggestion withdrawn. I'll add some documentation to copy_node. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-9058-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 21:02:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 504 invoked by alias); 12 Aug 1999 21:02:02 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 489 invoked from network); 12 Aug 1999 21:02:01 -0000 Received: from thor.xraylith.wisc.edu (198.150.6.11) by egcs.cygnus.com with SMTP; 12 Aug 1999 21:02:01 -0000 Received: from mercury.xraylith.wisc.edu (mercury.xraylith.wisc.edu [128.104.182.221]) by thor.xraylith.wisc.edu (8.9.1a/8.9.1) with ESMTP id QAA23913 for ; Thu, 12 Aug 1999 16:01:56 -0500 Received: from mercury.xraylith.wisc.edu (localhost [127.0.0.1]) by mercury.xraylith.wisc.edu (8.8.7/8.8.7) with ESMTP id QAA00896 for ; Thu, 12 Aug 1999 16:01:52 -0500 Message-Id: <199908122101.QAA00896@mercury.xraylith.wisc.edu> To: gcc@gcc.gnu.org Subject: Re: order of switches In-Reply-To: Your message of "Thu, 12 Aug 1999 13:26:35 PDT." <37B32DFB.DA4D6BBB@cs.ucla.edu> Date: Thu, 12 Aug 1999 16:01:52 -0500 From: Mumit Khan Igor Markov writes: > > well... thank you very much, but I've been working with SunCC > for 3+ years, am now porting to g++ and having problems > (which is why the question arose) Joe tries to help, and you come back with something that looks like whining, but in fact I just don't understand what you are trying to say. GCC and SunCC are two different compilers, and even though both share the standard "Unix-style" compiler switches, there can be and are subtle differences. And that's where the documentation comes in. > > The man pages are very minimal guides to the option flags. The real > > documentation of GCC is in the texinfo files. > > I get an impression of that this is some kind of conspiracy (gee !) > .. not sure, but, perhaps, to cause people to buy support ? > (yes, I understand one can look at this from difft angles ... but > once I have my angle, it may be difficult to convince me otherwise) > GCC comes with documentation. You can choose to read it or not. If you choose to read the documentation and find it confusing and lacking, there are many here who are willing to help (and you can help fill the gaps in the documentation; in case you didn't know, that's how free software works -- it's a two-way street). If you choose not to read it, don't come here whining. Please go away. Regards, Mumit From gcc-return-9059-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 21:08:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1607 invoked by alias); 12 Aug 1999 21:08:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1590 invoked from network); 12 Aug 1999 21:08:43 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 12 Aug 1999 21:08:43 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id OAA12195; Thu, 12 Aug 1999 14:07:46 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id OAA16278; Thu, 12 Aug 1999 14:07:45 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id OAA12333; Thu, 12 Aug 1999 14:07:45 -0700 Message-Id: <199908122107.OAA12333@atrus.synopsys.com> Subject: Re: order of switches To: imarkov@cs.ucla.edu (Igor Markov) Date: Thu, 12 Aug 99 14:07:45 PDT Cc: gcc@gcc.gnu.org In-Reply-To: <37B32DFB.DA4D6BBB@cs.ucla.edu>; from "Igor Markov" at Aug 12, 99 1:26 pm X-Mailer: ELM [version 2.3 PL11] Igor Markov writes: > I get an impression of that this is some kind of conspiracy (gee !) > .. not sure, but, perhaps, to cause people to buy support ? Yes. You've caught us. We made -I and -l work just like Unix -I and -l so you'd have to buy a support contract. But the Cabal (there is no Cabal) has decided that you couldn't pay us enough to make a support contract profitable, plus, any staff forced to deal with you would leave. So you've foiled our little plot. (Seriously, I don't sell support). > (yes, I understand one can look at this from difft angles ... but > once I have my angle, it may be difficult to convince me otherwise) I apologize to the list for encouraging Igor. Unless there is a radical change in his behavior and a profuse apology to everyone he has insulted, I won't be answering further mail from him. From gcc-return-9060-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 21:16:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4195 invoked by alias); 12 Aug 1999 21:16:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4179 invoked from network); 12 Aug 1999 21:16:12 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 12 Aug 1999 21:16:12 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA12312; Thu, 12 Aug 1999 14:16:11 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id OAA15896; Thu, 12 Aug 1999 14:16:11 -0700 Date: Thu, 12 Aug 1999 14:16:11 -0700 From: Richard Henderson To: Zack Weinberg Cc: law@cygnus.com, John Wehle , gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Message-ID: <19990812141611.A15891@cygnus.com> References: <199908122020.NAA24484@zack.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199908122020.NAA24484@zack.bitmover.com>; from Zack Weinberg on Thu, Aug 12, 1999 at 01:20:03PM -0700 On Thu, Aug 12, 1999 at 01:20:03PM -0700, Zack Weinberg wrote: > What we actually want is to do everything in SImode until the results > become visible outside a function - returning, or write to memory. Or comparison, or anything else that could detect overflow, like another addition. > I thought that inc MEM was discouraged on post-486. No, it's still very useful. E.g. on P2, inc mem is a 4 uop insn. Your three insn sequence also generates 4 uops, but takes up more decoders so we can only issue 4 uops in that cycle instead of 6. Plus, inc mem is 3 bytes min whereas your sequence is 7 bytes min. r~ From gcc-return-9061-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 21:26:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5360 invoked by alias); 12 Aug 1999 21:26:21 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5345 invoked from network); 12 Aug 1999 21:26:15 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 12 Aug 1999 21:26:15 -0000 Received: from cs.ucla.edu (ts39-11.wla.ts.ucla.edu [164.67.22.120]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id OAA21367; Thu, 12 Aug 1999 14:26:07 -0700 (PDT) Message-ID: <37B33CA4.A8DE3CC@cs.ucla.edu> Date: Thu, 12 Aug 1999 14:29:08 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Joe Buck CC: gcc@gcc.gnu.org Subject: Re: order of switches References: <199908122107.OAA12333@atrus.synopsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joe, seriously ... not sure what you mean by a *radical change*. I am trying to do my work with g++ and report the problems that I am encountering. I did get some very good help from the list in most cases. OTOH, I will be perfectly happy with *your* not replying to my messages, primarily because you are seem to be typing them in hurry and the answers are rarely helpful. As to the Cabal and profuse apology... if someone took this seriously, I do apologize. I know that people are generally doing a good job, mostly for free... The main thing that I've trying to convey (and many agreed to this already) is that the New Jersey approach is not a good approach for the late 90s, i.e., the balance between fundamental development and user convenience is significantly different. If you haven't learnt anything from looking at the success of M$, the failing of OS/2 etc etc (or are saying that "we are different")... I really have nothing left to say. The particular application of the above to the recent inquiries --- I do not know where exactly I was wrong and where the g++ developers forgot to plug something (e.g. man pages!). I know that I tried several things, in good faith, several times, giving it some thought .. etc etc. The replies that I got did not even honor reading my mail carefully. Hence, the attitude. Technically, it's cheaper to pay a hundred $$ for KAI and be happy with it, rather than waste time on such discussions. Cheers, Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-9062-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 21:27:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6253 invoked by alias); 12 Aug 1999 21:27: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6148 invoked from network); 12 Aug 1999 21:27:35 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 12 Aug 1999 21:27:35 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id SAA07269; Thu, 12 Aug 1999 18:22:06 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id RAA19032; Thu, 12 Aug 1999 17:50:25 -0300 (EST) To: Igor Markov Cc: Joe Buck , gcc@gcc.gnu.org Subject: Re: order of switches References: <199908122010.NAA11553@atrus.synopsys.com> <37B32DFB.DA4D6BBB@cs.ucla.edu> From: Alexandre Oliva Date: 12 Aug 1999 17:53:53 -0300 In-Reply-To: Igor Markov's message of "Thu, 12 Aug 1999 13:26:35 -0700" Message-ID: Lines: 46 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 12, 1999, Igor Markov wrote: >> the order of the switches most definitely matters for include file >> directories and libraries. > yes, that relates to the order, but that *does* seem trivial > (esp. that I am using the Makefiles which work with SunCC) > In one instance I had to move -l after the .o file > so that gcc does not silently ignore -l It doesn't. It passes it to the linker, that opens the library but figures out it doesn't need any symbol from it. Then it gets to the .o files. Maybe SunCC reorders flags, or some implicit object file it links in before any library imports the symbols you need from it. > In another instance I was bitten by both -Ixxx and -I being > legal (I defined STL="" because g++ has a good STL inside) `-I dir' is legal because some compilers accept it, SunCC included. You're the one causing the difference, by setting STL="", misled by whoever designed the Makefile in a way that makes it hard for one to disable the flag to search for STL. You could probably make it work with STL="unneeded" >> > I just grep'ed man g++ for "order" and it there were no matches. >> The man pages are very minimal guides to the option flags. The real >> documentation of GCC is in the texinfo files. > I get an impression of that this is some kind of conspiracy (gee !) > .. not sure, but, perhaps, to cause people to buy support ? texinfo has always been the documentation format recommended for GNU projects, and GCC's man-page points to the info files as the official documentation. texinfo is *much* easier to write than troff, and info files are as easy to read as man-pages (or easier, if you're a convert :-). You just need the proper tool (`info' or `emacs'). Or, if you prefer, you can use the printed version, generated from the texinfo files with `texinfo'. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9063-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 21:38:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12301 invoked by alias); 12 Aug 1999 21:38:40 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12255 invoked from network); 12 Aug 1999 21:38:36 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 12 Aug 1999 21:38:36 -0000 Received: from cs.ucla.edu (ts39-11.wla.ts.ucla.edu [164.67.22.120]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id OAA27365; Thu, 12 Aug 1999 14:38:20 -0700 (PDT) Message-ID: <37B33F81.E79F135D@cs.ucla.edu> Date: Thu, 12 Aug 1999 14:41:21 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Alexandre Oliva CC: Joe Buck , gcc@gcc.gnu.org Subject: Re: order of switches References: <199908122010.NAA11553@atrus.synopsys.com> <37B32DFB.DA4D6BBB@cs.ucla.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alexandre Oliva wrote: > > In one instance I had to move -l after the .o file > > so that gcc does not silently ignore -l > > It doesn't. It passes it to the linker, that opens the library but > figures out it doesn't need any symbol from it. > Then it gets to the .o files. Maybe SunCC reorders flags, or some implicit > object file it links in before any library imports the symbols you need from > it. Well.. I can say that with SunCC, when using shared libs, I never get "undefined" symbols due to bad ordering. (It's not as nice with static libs though). I think that, at minimum, it processes all libs and all object files in just two pieces, rather than "some libs first, then some object files, then more libs, more obj"... I can see that this may be somewhat limiting, but in practice it's much more convenient. > > In another instance I was bitten by both -Ixxx and -I being > > legal (I defined STL="" because g++ has a good STL inside) > > `-I dir' is legal because some compilers accept it, SunCC included. > You're the one causing the difference, by setting STL="", misled by > whoever designed the Makefile in a way that makes it hard for one to > disable the flag to search for STL. You could probably make it work > with STL="unneeded" that's right > >> > I just grep'ed man g++ for "order" and it there were no matches. > > >> The man pages are very minimal guides to the option flags. The real > >> documentation of GCC is in the texinfo files. hmm...man g++ never mentions textinfo (I saw other man pages doing that). To be honest, I am not a big fan of textinfo (I am a vi-head, and textinfo causes emacs) but at least I can browse HTML versions of all textinfo pages on RH6.0 Alexandre, don't take the conspiracy theory too close to your heart ;-) Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-9064-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 21:47:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16197 invoked by alias); 12 Aug 1999 21:47:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16138 invoked from network); 12 Aug 1999 21:47:36 -0000 Received: from gw.varesearch.com (HELO oxygen.su.varesearch.com) (@209.81.8.2) by egcs.cygnus.com with SMTP; 12 Aug 1999 21:47:36 -0000 Received: from hydrogen.su.varesearch.com ([10.1.0.1] helo=varesearch.com) by oxygen.su.varesearch.com with esmtp (Exim 2.12 #6) id 11F2hC-0007Na-00; Thu, 12 Aug 1999 14:47:34 -0700 Received: by varesearch.com (Postfix, from userid 561) id C9FE53FC1; Thu, 12 Aug 1999 14:47:33 -0700 (PDT) Subject: Re: Cross compile for g77 and objc To: law@cygnus.com Date: Thu, 12 Aug 1999 14:47:33 -0700 (PDT) Cc: egcs@egcs.cygnus.com, egcs-patches@egcs.cygnus.com In-Reply-To: <12308.934482120@upchuck.cygnus.com> from "Jeffrey A Law" at Aug 12, 1999 12:22:00 PM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990812214733.C9FE53FC1@varesearch.com> From: hjl@varesearch.com (H.J. Lu) > > > In message <19990812165338.C8A8F3FC1@varesearch.com>you write: > > I saw cross compile disabled for g77 and objc. I enabled it by hand. > > It seems to work for me from glibc 2 to libc 5 on x86. I also tried > > from glibc 2/x86 to glibc 2/ppc. > ?!? What are you talking about? > > Did you actually read the instructions we provide for building cross compilers? No. I used my old script. > > "make cross" is not the way to build cross compilers anymore. THe target > should be removed from the toplevel Makefile. > jeff > > Thanks. It works for me now. "make cross" did confuse me. Here is a libgcc2 patch for cross compile. When I do cross compile for Linux, I need a libgcc.a which is identical to the native compiled libgcc.a. The current libgcc2.c doesn't support it. I used the patch below to get around it. I added -Dno_inhibit_libc to my CFLAGS so that my cross compiled libgcc.a is the same as the native compiled libgcc.a. -- H.J. Lu (hjl@gnu.org) ---- Thu Aug 12 10:18:30 1999 H.J. Lu (hjl@gnu.org) * gcc/libgcc2.c (inhibit_libc): Don't define if no_inhibit_libc is defined. --- ../../import/gcc-2.95/egcs/gcc/libgcc2.c Sun Jun 13 10:55:04 1999 +++ gcc/libgcc2.c Wed Aug 11 17:13:19 1999 @@ -60,7 +60,7 @@ Boston, MA 02111-1307, USA. */ /* In a cross-compilation situation, default to inhibiting compilation of routines that use libc. */ -#if defined(CROSS_COMPILE) && !defined(inhibit_libc) +#if defined(CROSS_COMPILE) && !defined(inhibit_libc) && !defined(no_inhibit_libc) #define inhibit_libc #endif From gcc-return-9065-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 21:57:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18374 invoked by alias); 12 Aug 1999 21:57:52 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18351 invoked from network); 12 Aug 1999 21:57:50 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 12 Aug 1999 21:57:50 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id PAA13087; Thu, 12 Aug 1999 15:53:56 -0600 X-Mailer: exmh version 2.0.2 To: Igor Markov cc: Alexandre Oliva , Joe Buck , gcc@gcc.gnu.org Subject: Re: order of switches Reply-To: law@cygnus.com In-reply-to: Your message of Thu, 12 Aug 1999 14:41:21 PDT. <37B33F81.E79F135D@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Aug 1999 15:53:56 -0600 Message-ID: <13084.934494836@upchuck.cygnus.com> From: Jeffrey A Law In message <37B33F81.E79F135D@cs.ucla.edu>you write: > Well.. I can say that with SunCC, when using shared libs, > I never get "undefined" symbols due to bad ordering. > (It's not as nice with static libs though). I think that, > at minimum, it processes all libs and all object files in > just two pieces, rather than "some libs first, then some > object files, then more libs, more obj"... > I can see that this may be somewhat limiting, but in practice > it's much more convenient. Catch a clue. Read the manuals. Joe, Alexandre and others are correct, you are wrong. Unix linkers have worked this way for nearly 30 years. jeff From gcc-return-9066-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 22:12:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20155 invoked by alias); 12 Aug 1999 22:12:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20137 invoked from network); 12 Aug 1999 22:12:38 -0000 Received: from tahallah.demon.co.uk (root@194.222.9.116) by egcs.cygnus.com with SMTP; 12 Aug 1999 22:12:38 -0000 Received: from localhost (alex@tahallah.demon.co.uk [127.0.0.1]) by tahallah.demon.co.uk (8.9.3/8.9.0) with ESMTP id XAA00796; Thu, 12 Aug 1999 23:14:26 +0100 Date: Thu, 12 Aug 1999 23:14:26 +0100 (BST) From: Alex Buell X-Sender: alex@tahallah.demon.co.uk Reply-To: alex.buell@tahallah.demon.co.uk To: Jeffrey A Law cc: gcc@gcc.gnu.org Subject: Re: order of switches In-Reply-To: <13084.934494836@upchuck.cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 12 Aug 1999, Jeffrey A Law wrote: > Catch a clue. Read the manuals. Joe, Alexandre and others are > correct, you are wrong. Unix linkers have worked this way for nearly > 30 years. I've been watching this fuckwit troll the gcc mailing list, and I'm rapidly forming the opinion that he's obviously a troll. Cheers, Alex -- Legalise cannabis today! http://www.tahallah.demon.co.uk From gcc-return-9067-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 22:57:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24210 invoked by alias); 12 Aug 1999 22:57:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24195 invoked from network); 12 Aug 1999 22:57:40 -0000 Received: from hos.maad.com (root@206.124.28.7) by egcs.cygnus.com with SMTP; 12 Aug 1999 22:57:40 -0000 Received: from waterfall.internal.net (stargate.maad.com [206.124.28.111]) by hos.maad.com (8.8.7/8.8.7) with ESMTP id QAA25785 for ; Thu, 12 Aug 1999 16:12:07 -0600 Date: Thu, 12 Aug 1999 17:08:29 -0600 From: Anna Winkler X-Sender: awinkler@waterfall.internal.net To: GCC List Subject: Linker Error on Solaris 2.5.1 with GCC 2.95 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I'm compiling a 3rd party application on Solaris 2.5.1 with GCC 2.95. I installed the Solaris 2.5 freeware package of GCC 2.95, so it was not compiled on my system. At the final link stage, I get an error from ld: /usr/local/bin/make -j4 CC="g++" DEBUG="-g -pedantic -Wall -Wstrict-prototypes -DDEBUG_MENU " ipme make[1]: Entering directory `/export/home/awinkler/ipme1' g++ -o ipme -g -g -pedantic -Wall -Wstrict-prototypes -DDEBUG_MENU database/database.o measure/measure.o micro_models/micro_models.o environment/environment.o operator/operator.o resources/resources.o sockets/sockets.o hftd/hftd.o workspace/workspace.o psf/psf.o main/main.o workload/workload.o utils/utils.o user_interface/user_interface.o execSettings/execSettings.o ippct/ippct.o simulator/simulator_tot.o mem_model/mem_model.o -L/usr/local/lib/magick -L/usr/local/XRT/lib -L/usr/openwin/lib/X11 -L/usr/local/raima4.5.2/lib/sol2 -L/usr/lib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95/ -L/usr/dt/lib -L/usr/openwin/lib \ -lMagick -lxrtgear -lxrttable -lXpm -lXm -lXpm -lXt -lXext -lX11 -lm -lvistact -lvistamu -lXmu /usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95//libgcc.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [ipme] Error 1 I updated my path so that the ld in /usr/ccs/bin is the one found first (instead of the one in /usr/ucb/bin). Does anyone have any suggestions? Thanks very much, Anna Winkler From gcc-return-9068-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 23:22:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26887 invoked by alias); 12 Aug 1999 23:22:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26871 invoked from network); 12 Aug 1999 23:22:30 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 12 Aug 1999 23:22:30 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id UAA09576; Thu, 12 Aug 1999 20:14:08 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id UAA03028; Thu, 12 Aug 1999 20:14:09 -0300 (EST) To: Igor Markov Cc: Joe Buck , gcc@gcc.gnu.org Subject: Re: order of switches References: <199908122010.NAA11553@atrus.synopsys.com> <37B32DFB.DA4D6BBB@cs.ucla.edu> <37B33F81.E79F135D@cs.ucla.edu> From: Alexandre Oliva Date: 12 Aug 1999 20:18:00 -0300 In-Reply-To: Igor Markov's message of "Thu, 12 Aug 1999 14:41:21 -0700" Message-ID: Lines: 32 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 12, 1999, Igor Markov wrote: > Well.. I can say that with SunCC, when using shared libs, > I never get "undefined" symbols due to bad ordering. Then use shared libraries with gcc too. The way a linker processes shared libraries is completely different from static ones. > I can see that this may be somewhat limiting, but in practice > it's much more convenient. It's only more convenient for those that don't know the rules, and it would impose a severe limitation to those that do. > hmm...man g++ never mentions textinfo man gcc does. I didn't even know there was a g++ man-page :-) We'd welcome a patch for g++.1 that copies from gcc.1 the paragraph pointing to the info document. g++.1 lives in gcc-2.95/gcc/cp; gcc.1 lives in gcc-2.95/gcc. Thanks in advance. > (I am a vi-head, and textinfo causes emacs) There are stand-alone text- and x-based `info' browser, you don't need emacs for browsing info. In fact, I seldom use it for info browsing. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9069-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 23:25:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27812 invoked by alias); 12 Aug 1999 23:25: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27787 invoked from network); 12 Aug 1999 23:25:42 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 12 Aug 1999 23:25:42 -0000 Received: (qmail 11886 invoked by alias); 12 Aug 1999 23:25:39 -0000 Received: (qmail 11868 invoked from network); 12 Aug 1999 23:25:38 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 12 Aug 1999 23:25:38 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id AAA09526; Fri, 13 Aug 1999 00:24:26 +0100 From: Joern Rennecke Message-Id: <199908122324.AAA09526@phal.cygnus.co.uk> Subject: Re: big slowdown in egcs-1.1.2->gcc-2.95 on alpha In-Reply-To: <8288.934361630@upchuck.cygnus.com> from Jeffrey A Law at "Aug 11, 1999 2:53:50 am" To: law@cygnus.com Date: Fri, 13 Aug 1999 00:24:26 +0100 (BST) Cc: amylaar@cygnus.co.uk, lucier@math.purdue.edu, gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, staff@math.purdue.edu, hosking@cs.purdue.edu, wilker@math.purdue.edu, bernds@cygnus.com X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > * global.c (prune_preferences): Move some invariants out of the > > inner loop. > This patch is fine, even if it did not make a significant difference for > the compile time slowdown in question. Thanks. I have tested and comitted the patch. I think I understand the bottleneck in prune_preferences better. It is indeed the CONFLICTP check. We can expect the conflicts to be sparse, because typically we have a lot of pseudos that live only during a single basic block or during a loop. Moreover, CONFLICTS are naturally symmetric, yet as the comment for conflicts says: `conflicts' is not symmetric; a conflict between allocno's i and j is recorded either in element i,j or in element j,i. */ All CONFLICT_P tests are therefore duplicated, thus causing yet more unnecessary overhead. `conflicts' is not symmetric; a conflict between allocno's i and j is recorded either in element i,j or in element j,i. */ So, I think we can get better compiling performance for large programs if conflicts allocnos_live use a representation that is efficient for sparse sets, e.g. a hash table or a balanced tree. Moreover, it makes sense to normalize conflicts before we store them, e.g. we could say CONFLICTP (i, j) is normalized if i <= j. If the conflict is not normalized, swapping the operands will normalize it. Or if we go for hash tables and want to encourage a more uniform distribution of has table filling, we could say CONFLICTP (i, j) is normalized if (unsigned)(j - i) % n <= n >> 1 , where n is the total number of allocnos. This does not work for even allocnos, so we just bump up n to an odd number. The implementation is left as an exercise to the reader ;-) From gcc-return-9070-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 12 23:28:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29137 invoked by alias); 12 Aug 1999 23:28:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29122 invoked from network); 12 Aug 1999 23:28:55 -0000 Received: from mescaline.gnu.org (158.121.106.21) by egcs.cygnus.com with SMTP; 12 Aug 1999 23:28:55 -0000 Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.1.11]) by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id TAA01493 for ; Thu, 12 Aug 1999 19:28:35 -0400 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id UAA09636; Thu, 12 Aug 1999 20:18:08 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id UAA03161; Thu, 12 Aug 1999 20:18:10 -0300 (EST) To: Anna Winkler Cc: GCC List Subject: Re: Linker Error on Solaris 2.5.1 with GCC 2.95 References: From: Alexandre Oliva Date: 12 Aug 1999 20:22:02 -0300 In-Reply-To: Anna Winkler's message of "Thu, 12 Aug 1999 17:08:29 -0600" Message-ID: Lines: 27 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 12, 1999, Anna Winkler wrote: > I'm compiling a 3rd party application on Solaris 2.5.1 with GCC 2.95. I > installed the Solaris 2.5 freeware package of GCC 2.95, so it was not > compiled on my system. > /usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95//libgcc.a: could not read symbols: Bad value > I updated my path so that the ld in /usr/ccs/bin is the one found first The PATH doesn't make any difference, only what the command `gcc -print-prog-name=ld' prints does. I've got this very same problem when building gcc 2.95 when I configured it to use GNU ld and GNU as, but I hadn't updated my installation script to create the links to GNU ld and GNU as in the installation tree, as recommended in the FAQ (which I myself wrote! :-) Maybe the binary distribution you got is supposed to use ld and as from GNU binutils? Better check the docs. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9071-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 00:14:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32226 invoked by alias); 13 Aug 1999 00:14:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32209 invoked from network); 13 Aug 1999 00:14:23 -0000 Received: from hos.maad.com (root@206.124.28.7) by egcs.cygnus.com with SMTP; 13 Aug 1999 00:14:23 -0000 Received: from waterfall.internal.net (stargate.maad.com [206.124.28.111]) by hos.maad.com (8.8.7/8.8.7) with ESMTP id RAA26209; Thu, 12 Aug 1999 17:28:23 -0600 Date: Thu, 12 Aug 1999 18:24:45 -0600 From: Anna Winkler X-Sender: awinkler@waterfall.internal.net To: Alexandre Oliva cc: GCC List Subject: Re: Linker Error on Solaris 2.5.1 with GCC 2.95 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 12 Aug 1999, Alexandre Oliva wrote: > On Aug 12, 1999, Anna Winkler wrote: > > > I'm compiling a 3rd party application on Solaris 2.5.1 with GCC 2.95. I > > installed the Solaris 2.5 freeware package of GCC 2.95, so it was not > > compiled on my system. > > > /usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95//libgcc.a: could not read symbols: Bad value > > > I updated my path so that the ld in /usr/ccs/bin is the one found first > > The PATH doesn't make any difference, only what the command `gcc > -print-prog-name=ld' prints does. > > I've got this very same problem when building gcc 2.95 when I > configured it to use GNU ld and GNU as, but I hadn't updated my > installation script to create the links to GNU ld and GNU as in the > installation tree, as recommended in the FAQ (which I myself wrote! > :-) > > Maybe the binary distribution you got is supposed to use ld and as > from GNU binutils? Better check the docs. gcc -print-prog-name=ld returns /usr/local/sparc-sun-solaris2.5.1/bin. I added that to my path, so that's the first ld found, then recompiled. I still got the same linker error. Unfortunately there isn't much documentation with this binary distribution. --Anna From gcc-return-9072-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 02:09:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9299 invoked by alias); 13 Aug 1999 02:09: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9278 invoked from network); 13 Aug 1999 02:09:20 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 13 Aug 1999 02:09:19 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id XAA12418; Thu, 12 Aug 1999 23:05:11 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id XAA14979; Thu, 12 Aug 1999 23:05:08 -0300 (EST) To: Anna Winkler Cc: GCC List Subject: Re: Linker Error on Solaris 2.5.1 with GCC 2.95 References: From: Alexandre Oliva Date: 12 Aug 1999 23:09:02 -0300 In-Reply-To: Anna Winkler's message of "Thu, 12 Aug 1999 18:24:45 -0600" Message-ID: Lines: 19 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 12, 1999, Anna Winkler wrote: > gcc -print-prog-name=ld returns /usr/local/sparc-sun-solaris2.5.1/bin. I > added that to my path, so that's the first ld found, then > recompiled. As I told you, the PATH doesn't make any difference. Please read http://egcs.cygnus.com/faq.html#gas You may have to install binutils, that should be available wherever you downloaded the binary package from. It's likely to install itself wherever gcc will find it. If not, you'll have to create a soft-link, as explained in the FAQ. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9073-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 03:55:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20432 invoked by alias); 13 Aug 1999 03:55:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20417 invoked from network); 13 Aug 1999 03:55:39 -0000 Received: from linux01.gwdg.de (root@134.76.13.21) by egcs.cygnus.com with SMTP; 13 Aug 1999 03:55:39 -0000 Received: from RAS23-061.gwdg.de (RAS23-061.gwdg.de [134.76.23.61]) by linux01.gwdg.de (8.9.3/8.9.3) with SMTP id FAA14337; Fri, 13 Aug 1999 05:55:38 +0200 From: kthomas@linux01.gwdg.de (Philipp Thomas) To: Igor Markov Cc: gcc@gcc.gnu.org Subject: Re: order of switches Date: Fri, 13 Aug 1999 03:55:26 GMT Message-ID: <37c0854d.90645121@linux01.gwdg.de> References: <199908122010.NAA11553@atrus.synopsys.com> <37B32DFB.DA4D6BBB@cs.ucla.edu> In-Reply-To: <37B32DFB.DA4D6BBB@cs.ucla.edu> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Thu, 12 Aug 1999 13:26:35 -0700, Igor Markov wrote: > well... thank you very much, but I've been working with SunCC > for 3+ years, am now porting to g++ and having problems > (which is why the question arose) Well how about telling so in your first mail?=20 > oh, well... it looks people like reading 50% of email and > shoot a reply immediately. That's rarely useful. And it won't help you a bit accusing those that try to help you. >> The man pages are very minimal guides to the option flags. The real >> documentation of GCC is in the texinfo files. > > I get an impression of that this is some kind of conspiracy (gee !) > .. not sure, but, perhaps, to cause people to buy support ? You really have a way to make friends. First its our job to supply you = with binaries, now we conspire to get you to pay for support. Seems to have = been some heavy stuff that you smoked. Get real, man! Texinfo is the only official FSF form of documentation. If *that* wasn't supplied, you would have a reason to complain. > (yes, I understand one can look at this from difft angles ... but > once I have my angle, it may be difficult to convince me otherwise) Why should we want to convince you? Why should we care what you think? There are lots of other people that know better and that appreciate the efforts to supply them with a free compiler and also the efforts to help them with problems here on the list. Philipp --=20 Nothing would please me more than being able to hire ten programmers and deluge the hobby market with good software. -- Bill Gates, 1976 From gcc-return-9074-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 03:56:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21138 invoked by alias); 13 Aug 1999 03:56:37 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21111 invoked from network); 13 Aug 1999 03:56:35 -0000 Received: from cosmo.ktb.net (root@198.175.228.45) by egcs.cygnus.com with SMTP; 13 Aug 1999 03:56:35 -0000 Received: from sid.boxsoft.com (root@pm01-43.ktb.net [208.34.160.53]) by cosmo.ktb.net (8.9.3/KTBNET-4.0) with ESMTP id UAA22917; Thu, 12 Aug 1999 20:56:16 -0700 Received: from 3eye.boxsoft.com (patrick@3eye.boxsoft [192.168.69.3]) by sid.boxsoft.com (8.8.7/8.8.7) with ESMTP id UAA23727; Thu, 12 Aug 1999 20:59:19 -0700 Received: (from patrick@localhost) by 3eye.boxsoft.com (8.8.7/8.8.7) id VAA06399; Thu, 12 Aug 1999 21:00:28 -0700 From: patrick Message-Id: <199908130400.VAA06399@3eye.boxsoft.com> Subject: Re: order of switches To: law@cygnus.com Date: Thu, 12 Aug 1999 21:00:28 -0700 (PDT) Cc: gcc@gcc.gnu.org (gcc list (aka egcs)) In-Reply-To: <13084.934494836@upchuck.cygnus.com> from "Jeffrey A Law" at Aug 12, 99 03:53:56 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sometime in the late 1900s it was said: > In message <37B33F81.E79F135D@cs.ucla.edu>you write: > > Well.. I can say that with SunCC, when using shared libs, > > I never get "undefined" symbols due to bad ordering. > > (It's not as nice with static libs though). I think that, > > at minimum, it processes all libs and all object files in > > just two pieces, rather than "some libs first, then some > > object files, then more libs, more obj"... > > I can see that this may be somewhat limiting, but in practice > > it's much more convenient. > Catch a clue. Read the manuals. Joe, Alexandre and others are correct, you > are wrong. Unix linkers have worked this way for nearly 30 years. > > jeff my gosh ... that is a scary statement that you just made jeff. patrick From gcc-return-9075-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 04:22:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23722 invoked by alias); 13 Aug 1999 04:22:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23695 invoked from network); 13 Aug 1999 04:22:41 -0000 Received: from rtl.cygnus.com (HELO gluttony.geoffk.wattle.id.au) (205.180.230.21) by egcs.cygnus.com with SMTP; 13 Aug 1999 04:22:41 -0000 Received: (from geoffk@localhost) by gluttony.geoffk.wattle.id.au (8.9.3/8.9.3) id NAA00810; Fri, 13 Aug 1999 13:29:31 +1000 Date: Fri, 13 Aug 1999 13:29:31 +1000 Message-Id: <199908130329.NAA00810@gluttony.geoffk.wattle.id.au> From: Geoff Keating To: jbuck@synopsys.com CC: egcs@gcc.gnu.org In-reply-to: <199908121739.KAA07878@atrus.synopsys.com> (message from Joe Buck on Thu, 12 Aug 99 10:39:30 PDT) Subject: Re: Random C9X conformance notes References: <199908121739.KAA07878@atrus.synopsys.com> > From: Joe Buck > Date: Thu, 12 Aug 99 10:39:30 PDT > Cc: egcs@gcc.gnu.org > > Geoff Keating quotes the gcc manual: > > > > * `-2147483648' is positive. > > > > > > This is because 2147483648 cannot fit in the type `int', so > > > (following the ANSI C rules) its data type is `unsigned long int'. > > > Negating this value yields 2147483648 again. > > The manual is incorrect. It should read > > * `-2147483648' is positive for ports where `long' is 32 bits. > > On the Alpha, it is negative. In the early days, gcc had the 'all the > world's a Vax' disease, so this statement was true without qualification. Oh, I was just assuming "on a 32-bit machine" implicitly in the documentation. Probably that should be changed. > Geoff again: > > > If ANSI C really required this before, then this is a significant > > quiet change and may go away before the final standard (I'm looking at > > last August's draft). It may not. The draft does make it very clear > > that decimal constants are always signed. > > I don't see how C9X could drop this change. If long long is a true type > that is co-equal with other types, they have to do it this way. In ANSI > (ISO) C, if an integral constant doesn't fit in an int, we first see if it > fits in a long, and finally try unsigned long. In C9X, we try int, long, > and finally long long. This follows naturally if you say that long long > is a real type (though one could add unsigned long long as a final type, > it's arguably more natural to ask the user to give a U to get an unsigned > literal). > > One could argue that since GNU C supports long long, it should have been > using the C9X semantics all along. > > The change is less significant than it appears, because it's hard to > write programs that don't use 'long long' where you can observe the > difference. That is, if you use -2147483648 to initialize a 32-bit > value, you will get the same result for ANSI and C9X. This is true, although it's not _that_ hard. For instance, printf("%lx\n", 2147483648); > One possibility is for gcc to issue warnings for integral constants (that > have no U or LL qualifier) that don't fit in a long, but that do fit in an > unsigned long, since those are the constants that behave differently in > ANSI and C9X, and even in ANSI may have surprising results. The user > can always eliminate the warning by adding an explicit U or LL. We'd certainly want this, at least as an option. -- Geoffrey Keating From gcc-return-9076-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 05:13:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26436 invoked by alias); 13 Aug 1999 05:13:44 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26421 invoked from network); 13 Aug 1999 05:13:41 -0000 Received: from linux01.gwdg.de (root@134.76.13.21) by egcs.cygnus.com with SMTP; 13 Aug 1999 05:13:41 -0000 Received: from RAS23-081.gwdg.de (RAS23-081.gwdg.de [134.76.23.81]) by linux01.gwdg.de (8.9.3/8.9.3) with SMTP id HAA15364; Fri, 13 Aug 1999 07:13:44 +0200 From: kthomas@linux01.gwdg.de (Philipp Thomas) To: Igor Markov Cc: gcc@gcc.gnu.org Subject: Re: order of switches Date: Fri, 13 Aug 1999 05:13:33 GMT Message-ID: <37c499c4.95881560@linux01.gwdg.de> References: <199908122107.OAA12333@atrus.synopsys.com> <37B33CA4.A8DE3CC@cs.ucla.edu> In-Reply-To: <37B33CA4.A8DE3CC@cs.ucla.edu> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > OTOH, I will be perfectly happy with *your* not replying to my = messages, > primarily because you are seem to be typing them in hurry and the = answers > are rarely helpful. Now you *really* owe Joe an apology. He did understand you perfectly well and tried to answer you correctly. But you seem to have a neat way of ignoring the answers that don't suit you. Or you are really trying to troll. But then again, nah, that would imply you have a clue. > Hence, the attitude. Technically, it's cheaper to pay a hundred $$ = for KAI > and be happy with it, rather than waste time on such discussions. Excellent! Do that and most of us will be glad. One clueless ignorant = less on the list. And don't bother to answer this mail, as you're now one of the very few entries in my kill file. Philipp --=20 Nothing would please me more than being able to hire ten programmers and deluge the hobby market with good software. -- Bill Gates, 1976 From gcc-return-9077-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 06:43:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 592 invoked by alias); 13 Aug 1999 06:43:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 572 invoked from network); 13 Aug 1999 06:43:03 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 13 Aug 1999 06:43:03 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id AAA14282; Fri, 13 Aug 1999 00:40:03 -0600 X-Mailer: exmh version 2.0.2 To: Zack Weinberg cc: Richard Henderson , John Wehle , gcc@gcc.gnu.org Subject: Re: 2.95, x86: severe performance problems with short arithmetic Reply-To: law@cygnus.com In-reply-to: Your message of Thu, 12 Aug 1999 13:20:03 PDT. <199908122020.NAA24484@zack.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Aug 1999 00:40:03 -0600 Message-ID: <14279.934526403@upchuck.cygnus.com> From: Jeffrey A Law In message <199908122020.NAA24484@zack.bitmover.com>you write: > I did. One problem leaps out at me: PROMOTE_MODE does math in HImode > and fixes up the registers afterward - for example: Ugh. Why don't you look at WORD_REGISTER_OPERATIONS or something like that, which may be a better alternative. jeff From gcc-return-9078-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 08:08:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12200 invoked by alias); 13 Aug 1999 08:08:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12184 invoked from network); 13 Aug 1999 08:08:45 -0000 Received: from gull.prod.itd.earthlink.net (207.217.121.85) by egcs.cygnus.com with SMTP; 13 Aug 1999 08:08:45 -0000 Received: from earthlink.net (sdn-ar-001casfrMP195.dialsprint.net [158.252.208.197]) by gull.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id BAA02390; Fri, 13 Aug 1999 01:08:43 -0700 (PDT) Message-ID: <37B3D437.F37C9B77@earthlink.net> Date: Fri, 13 Aug 1999 01:15:53 -0700 From: Michael Gordon Weaver Reply-To: weaver@ieee.org X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org, weaver@ieee.org Subject: gcc2.95 installed Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit I have built and installed gcc2.95 on my system: powerpc-unknown-linux-gnulibc1 Besides installing the lastest version of binutils as recommended, I had to make a change to the file: gcc/config/rs6000/linux.h at line 39 to change '-m elf32ppclinux' to '-m elf32ppc'. This appears to be a flag passed to 'ld', and the version of gld I have recognizes '-m elf32ppc' but not '-m elf32ppclinux'. Thanks, Michael Weaver. From gcc-return-9079-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 09:07:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20728 invoked by alias); 13 Aug 1999 09:07:54 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20713 invoked from network); 13 Aug 1999 09:07:52 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 13 Aug 1999 09:07:52 -0000 Received: from cs.ucla.edu (ts36-2.wla.ts.ucla.edu [164.67.22.63]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id CAA11493; Fri, 13 Aug 1999 02:07:50 -0700 (PDT) Message-ID: <37B3E118.8750523D@cs.ucla.edu> Date: Fri, 13 Aug 1999 02:10:48 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Re: Linker Error on Solaris 2.5.1 with GCC 2.95 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit a comment on the troubles with g++ on Solaris --- Our Solaris sysadmin installed gcc2.95 w/o binutils, and it seemed to work (simple tests would compile, link and run) (we have a mix of 2.6 and 2.7). However, when I tried to link executables for a non-trivial package (which has been ported from SunCC to g++ on Linux and now passes regression tests 100%) I got screenfuls of linking errors re: libstdc++. (The same thing runs perfectly fine on Linux; also note that I had to change -soname and -sodir passed to GNU ld into -h and -R passed to Sun ld). Our sysadmin installed latest GNU binutils on my suggestion and, once gcc is reinstalled, I will try linking again. I'd be interested to hear (perhaps, in private?) from people who are successfully using g++2.95 with Sun ld on Solaris... and if such exist, would suggest that g++/gcc attempt to pass relevant options (like -soname / -sodir) to the linker properly translating them... (void were prohibited, certain restrictions apply ;-) at least give it a thought Igor P.S. Browsing through the output of gcc --dumpspecs, I see a fair number of dirs with "ucb", and thought that a possible mix of Sun's own and "ucb"-style utilities may cause trouble... just a wild thought. If someone is interested, look at http://vlsicad.cs.ucla.edu/~imarkov/gcc-specs-sol -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-9080-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 09:16:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21784 invoked by alias); 13 Aug 1999 09:15:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21769 invoked from network); 13 Aug 1999 09:15:55 -0000 Received: from smtp.ucla.edu (HELO serval.noc.ucla.edu) (169.232.10.57) by egcs.cygnus.com with SMTP; 13 Aug 1999 09:15:55 -0000 Received: from cs.ucla.edu (ts36-2.wla.ts.ucla.edu [164.67.22.63]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id CAA13130; Fri, 13 Aug 1999 02:15:53 -0700 (PDT) Message-ID: <37B3E2FC.50F6A320@cs.ucla.edu> Date: Fri, 13 Aug 1999 02:18:52 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: a suggestion Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It would be nice if gcc warned seeing things like gcc -I -Imydir i.e. what is supposed to be a dir, starts with a dash. As implied in earlier email, this can be easily caused by erronous Makefiles which define some variables to be empty. This has actually happened and seems realistic to prevent in the future. Cheers, Igor P.S. BTW, compared to CC -w2, g++ -Wall -pedantic does a very good job warning about potential problems in source code --- it caught a few rather risky things in the code I was porting. I am looking forward to being able to use -Weffc++ (however modified) after libstdc++ is cleaned. -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-9081-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 09:42:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26978 invoked by alias); 13 Aug 1999 09:42:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26957 invoked from network); 13 Aug 1999 09:42:04 -0000 Received: from smtp.ucla.edu (HELO serval.noc.ucla.edu) (169.232.10.57) by egcs.cygnus.com with SMTP; 13 Aug 1999 09:42:04 -0000 Received: from cs.ucla.edu (ts36-2.wla.ts.ucla.edu [164.67.22.63]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id CAA16179; Fri, 13 Aug 1999 02:41:54 -0700 (PDT) Message-ID: <37B3E915.46942B9D@cs.ucla.edu> Date: Fri, 13 Aug 1999 02:44:53 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: rth@cygnus.com, law@cygnus.com, gcc@egcs.cygnus.com Subject: Re: a few quick questions (-fPIC vs -fpic) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit a small (and not the last) follow-up on the -fPIC vs -fpic question --- While our sysadmin is struggling with g++ setup on Solaris, I tried -pic and -PIC with SunCC. To my surprise, -PIC ran ~4% faster than -pic (on top of -fast -O5). I will post g++ -fpic/-fPIC results and other comparisons against CC when our g++ setup becomes operational. Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-9082-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 11:59:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5266 invoked by alias); 13 Aug 1999 11:59:34 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5145 invoked from network); 13 Aug 1999 11:59:12 -0000 Received: from zeus.sws.ch (193.247.183.41) by egcs.cygnus.com with SMTP; 13 Aug 1999 11:59:12 -0000 Received: by zeus.sws.ch with Internet Mail Service (5.5.2448.0) id ; Fri, 13 Aug 1999 14:06:38 +0200 Message-ID: <1C16A87379C4D111BCDC0060B01A025C0F46F1@zeus.sws.ch> From: Raymond Roesch To: "'gcc@gcc.gnu.org'" Subject: NSUBSPA Date: Fri, 13 Aug 1999 14:06:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable dear author, I successfully installed gcc 2.8.1 on my properly installed hp-ux 11.0 using the HP 10.20 software depot.=20 When compiling I get the following error: # /opt/gcc/bin/gcc -o hello hello.c hello.c: In function `main': hello.c:3: warning: return type of `main' is not `int' as: "/var/tmp/cca06584.s", line 23: error 1052: Directive name not recognized -=20 NSUBSPA Is it due to hp-ux 10.20 incompatibility or what is missing in my environment. TIA Raymond R=F6sch ********************************************************** Raymond R=F6sch mailto:raymond.roesch@sws.ch SWS SoftWare Systems AG phone: +41 31 981 06 66 Freiburgstrasse 634 fax: +41 31 981 32 63 CH - 3172 Niederwangen http://www.sws.ch ********************************************************** From gcc-return-9083-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 13:37:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8482 invoked by alias); 13 Aug 1999 13:37:09 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8466 invoked from network); 13 Aug 1999 13:37:04 -0000 Received: from dragonfly.wolfram.com (root@140.177.10.12) by egcs.cygnus.com with SMTP; 13 Aug 1999 13:37:04 -0000 Received: from m.wolfram.com (root@m.wolfram.com [140.177.201.20]) by dragonfly.wolfram.com (8.8.8/8.8.8) with ESMTP id IAA15036; Fri, 13 Aug 1999 08:37:02 -0500 (CDT) Received: from localhost (johnnyb@localhost) by m.wolfram.com (8.9.3/8.9.2) with ESMTP id IAA24755; Fri, 13 Aug 1999 08:34:07 -0500 Date: Fri, 13 Aug 1999 08:34:07 -0500 (CDT) From: Jonathan Bartlett To: Raymond Roesch cc: "'gcc@gcc.gnu.org'" Subject: Re: NSUBSPA In-Reply-To: <1C16A87379C4D111BCDC0060B01A025C0F46F1@zeus.sws.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE 1) it is supposed to warn you if the return type of main is not int 2) gcc does not always work with the default assembler. Try grabbing the binutils as well. Jon On Fri, 13 Aug 1999, Raymond Roesch wrote: > dear author, >=20 > I successfully installed gcc 2.8.1 on my properly installed hp-ux 11.0 > using the HP 10.20 software depot.=20 >=20 > When compiling I get the following error: > # /opt/gcc/bin/gcc -o hello hello.c > hello.c: In function `main': > hello.c:3: warning: return type of `main' is not `int' > as: "/var/tmp/cca06584.s", line 23: error 1052: Directive name not > recognized -=20 > NSUBSPA >=20 > Is it due to hp-ux 10.20 incompatibility or what is missing in my > environment. >=20 > TIA > Raymond R=F6sch > ********************************************************** > Raymond R=F6sch mailto:raymond.roesch@sws.ch > SWS SoftWare Systems AG phone: +41 31 981 06 66 > Freiburgstrasse 634 fax: +41 31 981 32 63 > CH - 3172 Niederwangen http://www.sws.ch > ********************************************************** >=20 >=20 From gcc-return-9084-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 14:16:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14493 invoked by alias); 13 Aug 1999 14:16:01 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14473 invoked from network); 13 Aug 1999 14:15:59 -0000 Received: from tca1.dl.ac.uk (193.62.112.34) by egcs.cygnus.com with SMTP; 13 Aug 1999 14:15:59 -0000 Received: from localhost (kcm@localhost) by tca1.dl.ac.uk (8.9.3/8.9.3) with ESMTP id PAA25106; Fri, 13 Aug 1999 15:15:22 +0100 Date: Fri, 13 Aug 1999 15:15:21 +0100 (BST) From: Kevin Maguire To: craig@jcb-sc.com cc: David.Billinghurst@riotinto.com.au, egcs@egcs.cygnus.com Subject: Re: Testing g77 with LAPACK 3.0 In-Reply-To: <19990706141202.5189.qmail@deer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi This is from a while ago, but I note that in f90 CMPLX(1.0E0,1.0E0) == CMPLX(1.0D0,1.0D0) i.e. cmplx(.x.,.y.) returns a default complex type. This is independent of the types of its arguements, unless the optional kind argument is supplied. I have seen this in several F90 codes, and is (to many users) a not-so-obvious cause of loss of precision. I dont know about the g77 implementation of CMPLX. Kevin Craig wrote: > It is due to non-standard code, though it's a popular-enough idiom that, > perhaps, g77 should support it someday, at least for legacy code. > > Note that I'd recommend using a patch like this instead, to maintain > code readability: > > - ALPHA = ( ONE, -ONE ) > - BETA = ( TWO, -TWO ) > + ALPHA = CMPLX ( ONE, -ONE ) > + BETA = CMPLX ( TWO, -TWO ) > RALPHA = ONE > RBETA = TWO > * > --- BLAS/TESTING/cblat3.f.0 Sun Jun 9 12:15:54 1996 > +++ BLAS/TESTING/cblat3.f Mon Jul 5 11:50:16 1999 > @@ -1989,8 +1989,8 @@ > * > * Initialize ALPHA, BETA, RALPHA, and RBETA. > * > - ALPHA = ( ONE, -ONE ) > - BETA = ( TWO, -TWO ) > + ALPHA = CMPLX ( ONE, -ONE ) > + BETA = CMPLX ( TWO, -TWO ) > > tq vm, (burley) > From gcc-return-9085-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 14:49:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20897 invoked by alias); 13 Aug 1999 14:49: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20872 invoked from network); 13 Aug 1999 14:49:20 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 13 Aug 1999 14:49:20 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with SMTP id KAA00951 for ; Fri, 13 Aug 1999 10:49:18 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com by world.std.com (TheWorld/Spike-2.0) id AA19725; Fri, 13 Aug 1999 10:48:24 -0400 Received: (qmail 8898 invoked by uid 500); 13 Aug 1999 14:48:03 -0000 Date: 13 Aug 1999 14:48:03 -0000 Message-Id: <19990813144803.8897.qmail@deer> To: kcm@tca1.dl.ac.uk Cc: David.Billinghurst@riotinto.com.au, egcs@egcs.cygnus.com Cc: craig@jcb-sc.com In-Reply-To: (message from Kevin Maguire on Fri, 13 Aug 1999 15:15:21 +0100 (BST)) Subject: Re: Testing g77 with LAPACK 3.0 References: >I dont know about the g77 implementation of CMPLX. Same as F90, according to the docs. (Which are generated from the same data base from which *some* of the pertinent code is generated, so I'd expect the docs and compiler to agree.) So, you're right, I shouldn't just recommend substituting CMPLX(A,B) for (A,B) in extended FORTRAN 77 code, since (A,B) presumably is DOUBLE COMPLEX when A or B are DOUBLE PRECISION. tq vm, (burley) From gcc-return-9086-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 15:39:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27874 invoked by alias); 13 Aug 1999 15:39:34 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27859 invoked from network); 13 Aug 1999 15:39:32 -0000 Received: from smtprch1.nortelnetworks.com (HELO smtprch1.nortel.com) (192.135.215.14) by egcs.cygnus.com with SMTP; 13 Aug 1999 15:39:32 -0000 Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Fri, 13 Aug 1999 10:31:48 -0500 Received: from zmtlde5a.ca.nortel.com ([47.64.13.90]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id P2BGZ2C2; Fri, 13 Aug 1999 11:39:19 -0400 Received: from wmtl249c.nortel.ca (wmtl249c.ca.nortel.com [47.64.3.156]) by zmtlde5a.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PRPKXR84; Fri, 13 Aug 1999 11:39:19 -0400 From: "Jerry Quinn" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14260.15397.891548.601227@gargle.gargle.HOWL> Date: Fri, 13 Aug 1999 11:39:17 -0400 (EDT) To: Raymond Roesch Cc: "'gcc@gcc.gnu.org'" Subject: NSUBSPA In-Reply-To: <1C16A87379C4D111BCDC0060B01A025C0F46F1@zeus.sws.ch> References: <1C16A87379C4D111BCDC0060B01A025C0F46F1@zeus.sws.ch> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) X-Orig: >> "Raymond" == Raymond Roesch writes: Raymond> dear author, I successfully installed gcc 2.8.1 on my properly Raymond> installed hp-ux 11.0 using the HP 10.20 software depot. Raymond> When compiling I get the following error: # /opt/gcc/bin/gcc -o Raymond> hello hello.c hello.c: In function `main': hello.c:3: warning: Raymond> return type of `main' is not `int' as: "/var/tmp/cca06584.s", line Raymond> 23: error 1052: Directive name not recognized - NSUBSPA This looks like you configured gcc to use the GNU assembler, but gcc can't find the assembler. For 2.7.2 and earlier, I found that on HP, I would have to actually copy or link gas into the gcc build subdirectory for gcc to find it. With gcc 2.95 (consider upgrading :-), you install gas with the same path and exec path as gcc and it will work fine. -- Jerry Quinn Tel: (514) 761-8737 jquinn@nortelnetworks.com Fax: (514) 761-8505 Speech Recognition Research From gcc-return-9087-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 15:45:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29327 invoked by alias); 13 Aug 1999 15:45:52 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29284 invoked from network); 13 Aug 1999 15:45:47 -0000 Received: from cg667526-a.adubn1.nj.home.com (HELO drow.them.org) (mail@24.2.213.175) by egcs.cygnus.com with SMTP; 13 Aug 1999 15:45:47 -0000 Received: from drow by drow.them.org with local (Exim 3.02 #1 (Debian)) id 11FJZ8-0006CM-00; Fri, 13 Aug 1999 11:48:22 -0400 Date: Fri, 13 Aug 1999 11:48:22 -0400 From: Daniel Jacobowitz To: weaver@ieee.org Cc: gcc@gcc.gnu.org Subject: Re: gcc2.95 installed Message-ID: <19990813114822.A23813@them.org> References: <37B3D437.F37C9B77@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.12i In-Reply-To: <37B3D437.F37C9B77@earthlink.net>; from Michael Gordon Weaver on Fri, Aug 13, 1999 at 01:15:53AM -0700 On Fri, Aug 13, 1999 at 01:15:53AM -0700, Michael Gordon Weaver wrote: > I have built and installed gcc2.95 on my system: > > powerpc-unknown-linux-gnulibc1 > > Besides installing the lastest version of binutils as recommended, > I had to make a change to the file: > > gcc/config/rs6000/linux.h > > at line 39 to change '-m elf32ppclinux' to '-m elf32ppc'. > This appears to be a flag passed to 'ld', and the version > of gld I have recognizes '-m elf32ppc' but not '-m elf32ppclinux'. What was your 'latest version of binutils'? elf32ppclinux is supported in snapshots from mid-2.9.4 and on; Franz Sirl has SRPMS available on ftp.linuxppc.org for it, although it hasn't been built for gnulibc1 that I know of. Dan /--------------------------------\ /--------------------------------\ | Daniel Jacobowitz |__| SCS Class of 2002 | | Debian GNU/Linux Developer __ Carnegie Mellon University | | dan@debian.org | | dmj+@andrew.cmu.edu | \--------------------------------/ \--------------------------------/ From gcc-return-9088-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 16:19:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3695 invoked by alias); 13 Aug 1999 16:19:24 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3680 invoked from network); 13 Aug 1999 16:19:22 -0000 Received: from alecto.physics.uiuc.edu (130.126.8.20) by egcs.cygnus.com with SMTP; 13 Aug 1999 16:19:22 -0000 Received: from localhost (menscher@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) with SMTP id LAA27534 for ; Fri, 13 Aug 1999 11:19:21 -0500 (CDT) X-Authentication-Warning: alecto.physics.uiuc.edu: menscher owned process doing -bs Date: Fri, 13 Aug 1999 11:19:20 -0500 (CDT) From: Damian Menscher X-Sender: menscher@alecto.physics.uiuc.edu To: gcc@gcc.gnu.org Subject: gcc-2.95.1 ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Someone on the bugs list told me a bug I need fixed is fixed in gcc-2.95.1. Has this been released (the Aug 8 snapshot) or has a release date been scheduled? Thanks, Damian Menscher -- --==## Grad. student & Sys. Admin. @ U. Illinois at Urbana-Champaign ##==-- --==## www.uiuc.edu/~menscher/ Ofc:(217)333-0038 ##==-- --==## Physics Dept, 1110 W Green, Urbana IL 61801 Fax:(217)333-9819 ##==-- From gcc-return-9089-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 16:35:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7316 invoked by alias); 13 Aug 1999 16:35:20 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7291 invoked from network); 13 Aug 1999 16:35:19 -0000 Received: from linuxpc1.lauterbach.com (qmailr@194.195.165.177) by egcs.cygnus.com with SMTP; 13 Aug 1999 16:35:19 -0000 Received: (qmail 12549 invoked from network); 13 Aug 1999 16:35:15 -0000 Received: from frapc1.lauterbach.com (HELO frapc1) (192.149.90.33) by linuxpc1 with SMTP; 13 Aug 1999 16:35:15 -0000 Message-Id: <4.2.0.58.19990813183422.03fc9f00@mail.lauterbach.com> X-Sender: fsirl-kernel@mail.lauterbach.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 13 Aug 1999 18:35:12 +0200 To: weaver@ieee.org From: Franz Sirl Subject: Re: gcc2.95 installed Cc: gcc@gcc.gnu.org,weaver@ieee.org In-Reply-To: <37B3D437.F37C9B77@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:15 13.08.99 , Michael Gordon Weaver wrote: >I have built and installed gcc2.95 on my system: > >powerpc-unknown-linux-gnulibc1 > >Besides installing the lastest version of binutils as recommended, >I had to make a change to the file: > >gcc/config/rs6000/linux.h > >at line 39 to change '-m elf32ppclinux' to '-m elf32ppc'. >This appears to be a flag passed to 'ld', and the version >of gld I have recognizes '-m elf32ppc' but not '-m elf32ppclinux'. You need binutils-2.9.4.0.8 or newer on Linux/PPC. You can grab it from . Franz. From gcc-return-9090-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 16:58:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9918 invoked by alias); 13 Aug 1999 16:58:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9903 invoked from network); 13 Aug 1999 16:58:24 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 13 Aug 1999 16:58:24 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id JAA00694; Fri, 13 Aug 1999 09:53:59 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id JAA04791; Fri, 13 Aug 1999 09:53:59 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id JAA19396; Fri, 13 Aug 1999 09:53:58 -0700 Message-Id: <199908131653.JAA19396@atrus.synopsys.com> Subject: Re: gcc-2.95.1 ? To: menscher@uiuc.edu (Damian Menscher) Date: Fri, 13 Aug 99 9:53:58 PDT Cc: gcc@gcc.gnu.org In-Reply-To: ; from "Damian Menscher" at Aug 13, 99 11:19 am X-Mailer: ELM [version 2.3 PL11] > Someone on the bugs list told me a bug I need fixed is fixed in > gcc-2.95.1. Has this been released (the Aug 8 snapshot) or has a release > date been scheduled? The plan is to put 2.95.1 out on August 15th, unless some last-minute reason is found to delay it (so that's not a promise). In addition to critical bug fixes, 2.95.1 will also have a cleaned-up version of the gcc manual (some documentation changes missed the release date for 2.95), so anyone who wants to print the thing should wait and save paper. From gcc-return-9091-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 17:01:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11622 invoked by alias); 13 Aug 1999 17:01:30 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11601 invoked from network); 13 Aug 1999 17:01:28 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 13 Aug 1999 17:01:28 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id KAA15851; Fri, 13 Aug 1999 10:58:10 -0600 X-Mailer: exmh version 2.0.2 To: Damian Menscher cc: gcc@gcc.gnu.org Subject: Re: gcc-2.95.1 ? Reply-To: law@cygnus.com In-reply-to: Your message of Fri, 13 Aug 1999 11:19:20 CDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Aug 1999 10:58:09 -0600 Message-ID: <15848.934563489@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > Someone on the bugs list told me a bug I need fixed is fixed in > gcc-2.95.1. Has this been released (the Aug 8 snapshot) or has a release > date been scheduled? gcc-2.95.1 will be released within the next few days. It froze except for doc fixes yesterday. jeff From gcc-return-9092-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 18:32:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24953 invoked by alias); 13 Aug 1999 18:31:53 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24921 invoked from network); 13 Aug 1999 18:31:44 -0000 Received: from cormoran.tsc.uc3m.es (163.117.145.202) by egcs.cygnus.com with SMTP; 13 Aug 1999 18:31:44 -0000 Received: from ieee.org ([127.0.0.1]) by cormoran.tsc.uc3m.es (Netscape Messaging Server 3.6) with ESMTP id AAA5EAF; Fri, 13 Aug 1999 20:31:33 +0200 Message-ID: <37B46468.E3592D0B@ieee.org> Date: Fri, 13 Aug 1999 20:31:09 +0200 From: Harold Molina-Bulla Organization: Grupo de Teoria de la =?iso-8859-1?Q?Se=F1al?= y Comunicaciones X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: es-CO, es-ES, en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: gcc-2.95 with 64 bits enable under Solaris 7 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms90800EA0EBB26A4B25ECD57B" This is a cryptographically signed message in MIME format. --------------ms90800EA0EBB26A4B25ECD57B Content-Type: multipart/mixed; boundary="------------082CAB7940D6E2DA9383DC07" This is a multi-part message in MIME format. --------------082CAB7940D6E2DA9383DC07 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi: I try to generate a 64 bits enabled compiler for my Ultrasparc WS. (I know, gcc-2.95 don't support Sparcv9 64 bits) I can do that with the sparcv9-sun-solaris2.7 target. The complete configuration command line is: configure --without-gnu-as --without-gnu-ld --enable-multilib --enable-shared --with-cpu=v8 sparcv9-sun-solaris2.7 It compiler with some problems: In stage2, sometimes the compilations break, some problem with the new cpp program (says "Bad executable format", but the program is OK (??)). Restart the compilation and finish. The compare stage is OK Now, when compile the runtime libraries have more problems The libiberty configuration for sparcv9 have errors: The symbols sys_nerr and sys_errlist are available for 32 bits architecture in the libc library, but not for 64 bits arch (see /usr/include/errno.h). When configure the Makefile in sparcv9 target, the configure program uses the "gcc" comand, and not the "gcc -m64" command, and detect this symbols. When create the libstdc++.so, and compile some program, this symbols not exists and the link stage fail. The gcc can't create shared libraries (fail when try to create the libstdc++.so and sparcv9/libstdc++.so libs), fails with and without the -m64 option; but creates the object files OK. Solution: use the system linker (/usr/ccs/bin/ld, with the same comand for gcc: "ld -G -h libstdc++.so.2.10.0 -o libstdc++.so.2.10.0 `cat piclist` -lm"). Solved this problems it work (not always good, but work). In some cases fails (have problems with the new libstdc++-2.90.6, and some java files in the libgcj-2.95) Good Luck for the developers. --------------082CAB7940D6E2DA9383DC07 Content-Type: text/x-vcard; charset=us-ascii; name="h.molina.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Harold Molina-Bulla Content-Disposition: attachment; filename="h.molina.vcf" begin:vcard n:Molina-Bulla;Harold tel;cell:+34.909032198 tel;fax:+34.916249430 tel;work:+34.916249903 x-mozilla-html:TRUE url:http://alcaudon.tsc.uc3m.es/~hmolina org: Universidad Carlos III de Madrid;Departamento de Tecnologías de las Comunicaciones version:2.1 email;internet:h.molina@ieee.org adr;quoted-printable:;;Escuela Polit=E9cnica Superior
=0D=0AC./ Butarque, 15;Leganes;Madrid;28911;Spain x-mozilla-cpt:;-7144 fn:Harold Molina-Bulla end:vcard --------------082CAB7940D6E2DA9383DC07-- --------------ms90800EA0EBB26A4B25ECD57B Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIXAYJKoZIhvcNAQcCoIIITTCCCEkCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BgkwggLIMIICMaADAgECAgJY/jANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5 OC45LjE2MB4XDTk4MTIxNDExMzg1MVoXDTk5MTIxNDExMzg1MVowQzEfMB0GA1UEAxMWVGhh d3RlIEZyZWVtYWlsIE1lbWJlcjEgMB4GCSqGSIb3DQEJARYRaC5tb2xpbmFAaWVlZS5vcmcw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALuRNMypPWgdffW70bECFNEQTcvvPR8f5Thj x9DtltoRaTc+zFwHepujc8i6EGSUtiUnRMNX2NFXLagSPQc1Tpoo+HAmE/6ZoVH/XSASv1Kd SM6mh85sG45uJVYuIzR2XFUIXtBz6pQTHBtr45+ND6oYXJBl1IaSY6WNxl2hh95DAgMBAAGj VDBSMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAf BgNVHSMEGDAWgBT+PmCca4wPsNgzxsrGHliwcTi14DANBgkqhkiG9w0BAQQFAAOBgQB6/N7L HOpKP9pHgFZa73NSAi9DVuAUJN2HyaI/iyc4OpQcfSlFVomO+/aTrs2HhxMVBnmCtQ7UEzRX CaEmxPWF6qQ83JbxQN/SrxdVxdu3cbGKavofv/J2BBOtRoQvcVizR+STf79zo0IWL8Fq1qXI sxNpNoocNiPxVxKAThPfLTCCAzkwggKioAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05ODA5MTYx NzU1MzRaFw0wMDA5MTUxNzU1MzRaMIG5MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3OjU1MTYwNAYDVQQD Ey1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3VlciAxOTk4LjkuMTYwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSl5dTU0F8IAu4HIX0kv6trjh7rIAcCFYRrj9CTJB8b ne5osrksT+mTZxcQFx6h+UNBI7kwqnaXu/Pn/YHAtTGL9qZQJlTylSjrGaQelx6w4ribwQSa MtA8CWxP5DVP8Ha/ABMDT0UIYPP8tNCQAYoSyZy6f1LqKpM1Njw85DUvAgMBAAGjNzA1MBIG A1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJ KoZIhvcNAQEEBQADgYEALMeCHwFDPgeP7mlcqWSC+MCWrZMry5tQ10CagcK6pnadPJVA3FXB 4VWCeasKKabVDOFXKD6P+bvV3w2TWKpbLYuPM+TdWBU1dnIVKb1C9FqSC3dfnSfbmi1OG4IG jtKNVruV3tsMZQXelZ4C3VMXvr78a8MaInoUK2G9wp9eeloxggIbMIICFwIBATCBwDCBuTEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmls bGUxGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNB IElLIDE5OTguOS4xNiAxNzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IFJTQSBJc3N1ZXIgMTk5OC45LjE2AgJY/jAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MDgxMzE4MzExNVowIwYJKoZIhvcNAQkE MRYEFJgx5jC5WtaTolpGzzi3el0JoSmfMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MA0GCSqGSIb3DQEBAQUABIGAVErqMD1dRAG/tAKVFEHxy7YrlxJVVOcjpM63BmHPeCXcFYmA mFw1p6z8mJOlQSmtF3HwCQ8LaiLHGcLg7oX6Dg0tK87Erm+TlXzAkWxy0UocjWBfH/IACWeg TYYZJNb+DRa8dIB/wkYXei434cGXqeKm1ZstLyoqmuHXZMEpkvI= --------------ms90800EA0EBB26A4B25ECD57B-- From gcc-return-9093-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 18:38:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27008 invoked by alias); 13 Aug 1999 18:37:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26989 invoked from network); 13 Aug 1999 18:37:49 -0000 Received: from birch.ripe.net (193.0.1.96) by egcs.cygnus.com with SMTP; 13 Aug 1999 18:37:49 -0000 Received: from ripe.net (x48.ripe.net [193.0.1.48]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id UAA13027 for ; Fri, 13 Aug 1999 20:37:47 +0200 (CEST) Message-Id: <199908131837.UAA13027@birch.ripe.net> To: gcc@gcc.gnu.org Subject: built gcc 2.95 on i386-pc-bsdi3.1 From: Roderik Muit X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Fri, 13 Aug 1999 20:37:46 +0200 A note, as requested on http://egcs.cygnus.com/install/finalinstall.html: I successfully built _most of_ gcc 2.95 on a i386-pc-bsdi3.1 system; built with --enable-languages=c++,objc,f77,java, i.e. no CHILL. (The first time I tried, I left out --enable-languages, an error was generated while compiling libchill/format.c. I do not have all details of the error and do not know much about the gcc compilation process, sorry. Here follows what I remember looking at some 2 hours ago, in case you're interested: I know some xgcc was compiling libchill/format.c but I don't know in which stage. The error produced was "illegal assembly instruction" (or something like that) - the illegal instruction which made was "filds (%SOMETHING)" (where I don't remember what SOMETHING was.) As far as I know I was using gas 2.9.1 as assembler, not the BSDI standard one. I looked through the configure process and saw that it was apparently setting HAVE_GAS_FILDS_FISTS. I don't know what's incorrect here since I know nothing about assembly. If you're really interested in the exact error I can try building it again... ) Thanks for GCC! Roderik. From gcc-return-9094-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 19:32:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1670 invoked by alias); 13 Aug 1999 19:32:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1655 invoked from network); 13 Aug 1999 19:32:49 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 13 Aug 1999 19:32:49 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA15245; Fri, 13 Aug 1999 12:32:49 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id MAA01954; Fri, 13 Aug 1999 12:32:48 -0700 Date: Fri, 13 Aug 1999 12:32:48 -0700 From: Richard Henderson To: "Kaveh R. Ghazi" Cc: egcs@egcs.cygnus.com Subject: Re: What should -Wmissing-noreturn do with "int main(){exit(0);}" ? Message-ID: <19990813123248.C1896@cygnus.com> References: <199908121902.PAA29751@caip.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199908121902.PAA29751@caip.rutgers.edu>; from Kaveh R. Ghazi on Thu, Aug 12, 1999 at 03:02:02PM -0400 On Thu, Aug 12, 1999 at 03:02:02PM -0400, Kaveh R. Ghazi wrote: > > int main() { exit(0); } > > foo.c: In function `main': > foo.c:1: warning: function might be possible candidate for > attribute `noreturn' > > The diagnostic is technically correct, but perhaps it should do > something different here. I see two alternatives. Since the diag is correct, is there any need to change it at all? I don't see any reason to... r~ From gcc-return-9095-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 19:40:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3464 invoked by alias); 13 Aug 1999 19:40:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3446 invoked from network); 13 Aug 1999 19:40:56 -0000 Received: from inet16.us.oracle.com (209.246.15.50) by egcs.cygnus.com with SMTP; 13 Aug 1999 19:40:56 -0000 Received: from usmail04 (usmail04.us.oracle.com [144.25.88.96]) by inet16.us.oracle.com (8.9.2/8.8.5) with SMTP id MAA26620 for ; Fri, 13 Aug 1999 12:38:20 -0700 (PDT) Received: from us.oracle.com by usmail04 with ESMTP (SMI-8.6/37.9) id MAA10986; Fri, 13 Aug 1999 12:40:55 -0700 Message-ID: <37B476EA.BE7DDB1F@us.oracle.com> Date: Fri, 13 Aug 1999 12:50:02 -0700 From: chandra Organization: Oracle Corp X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org CC: cpuchaka@us.oracle.com Subject: Gcc Fails during ld phase for automatic instantiation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am compiling my code on linux/GNU . I Compiled template-using code with `-frepo'. The compiler generated files with the extension `.rpo' listing all of the template instantiations . But when I try to create the final executable I see lot of undefined reference. ld Error is collect2: ld returned 1 exit status Question ? Do I need to use any other flag other then -frepo. Thank's in advance. Best regards, Chandra From gcc-return-9096-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 19:55:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6247 invoked by alias); 13 Aug 1999 19:54:53 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6231 invoked from network); 13 Aug 1999 19:54:46 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 13 Aug 1999 19:54:46 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA17620; Fri, 13 Aug 1999 12:54:39 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id MAA02011; Fri, 13 Aug 1999 12:54:39 -0700 Date: Fri, 13 Aug 1999 12:54:39 -0700 From: Richard Henderson To: Jonathan Bartlett Cc: gcc@gcc.gnu.org, kenner@vlsi1.ultra.nyu.edu Subject: Re: Toy language Message-ID: <19990813125439.D1896@cygnus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: ; from Jonathan Bartlett on Sat, Aug 07, 1999 at 09:34:27PM -0500 On Sat, Aug 07, 1999 at 09:34:27PM -0500, Jonathan Bartlett wrote: > In case anyone's interested, I've updated the toy language(a short, simple > language meant to give an example of a GCC front-end) to work with GCC > 2.95. It is available at http://members.wri.com/johnnyb/compilers/ for > anyone who's interested. I've added a link from the gcc readings page. r~ From gcc-return-9097-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 20:08:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8991 invoked by alias); 13 Aug 1999 20:08:37 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8976 invoked from network); 13 Aug 1999 20:08:35 -0000 Received: from birch.ripe.net (193.0.1.96) by egcs.cygnus.com with SMTP; 13 Aug 1999 20:08:35 -0000 Received: from ripe.net (x48.ripe.net [193.0.1.48]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id WAA17036; Fri, 13 Aug 1999 22:08:32 +0200 (CEST) Message-Id: <199908132008.WAA17036@birch.ripe.net> to: gcc@gcc.gnu.org, bug-gcc@gnu.org Subject: Re: built gcc 2.95 on i386-pc-bsdi3.1 In-reply-to: Your message of Fri, 13 Aug 1999 20:37:46 +0200. From: Roderik Muit X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Fri, 13 Aug 1999 22:08:32 +0200 Oops! I was too early with my message to gcc@gcc.gnu.org I _built_ gcc 2.95 on a i386-pc-bsdi3.1 system, but the resulting compiler produces invalid assembly code - as could be expected from my original message... I browsed the 'bugs' section of the info manual, but found no mention of a similar situation. So here comes the bugreport. What I get while compiling (ScrollBar.c, part of LessTif), is: ScrollBar.s: Assembler messages: ScrollBar.s:8933: Error: no such 386 instruction: `filds' ScrollBar.s:8940: Error: no such 386 instruction: `filds' In the next message, only to , follows: - lines 8933 - 8941 of ScrollBar.s - output of command (standard, as requested) - Scrollbar.i.gz, uuencoded (standard, as requested) So if `filds' is an illegal instruction, is gcc 2.95's `configure' script wrong in defining HAVE_GAS_FILDS_FISTS? I'm >90% sure I've seen it defining that... Thanks, Roderik. From gcc-return-9098-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 21:02:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14317 invoked by alias); 13 Aug 1999 21:02:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14302 invoked from network); 13 Aug 1999 21:02:54 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 13 Aug 1999 21:02:54 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id PAA16499; Fri, 13 Aug 1999 15:00:09 -0600 X-Mailer: exmh version 2.0.2 To: Roderik Muit cc: gcc@gcc.gnu.org, bug-gcc@gnu.org Subject: Re: built gcc 2.95 on i386-pc-bsdi3.1 Reply-To: law@cygnus.com In-reply-to: Your message of Fri, 13 Aug 1999 22:08:32 +0200. <199908132008.WAA17036@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Aug 1999 15:00:09 -0600 Message-ID: <16496.934578009@upchuck.cygnus.com> From: Jeffrey A Law In message <199908132008.WAA17036@birch.ripe.net>you write: > What I get while compiling (ScrollBar.c, part of LessTif), is: > ScrollBar.s: Assembler messages: > ScrollBar.s:8933: Error: no such 386 instruction: `filds' > ScrollBar.s:8940: Error: no such 386 instruction: `filds' > > In the next message, only to , follows: > - lines 8933 - 8941 of ScrollBar.s > - output of command (standard, as requested) > - Scrollbar.i.gz, uuencoded (standard, as requested) > > So if `filds' is an illegal instruction, is gcc 2.95's `configure' > script wrong in defining HAVE_GAS_FILDS_FISTS? I'm >90% sure I've seen > it defining that... What assembler are you using? I believe filds is a valid instruction on the x86 architecture. jeff From gcc-return-9099-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 13 22:27:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21103 invoked by alias); 13 Aug 1999 22:27:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21066 invoked from network); 13 Aug 1999 22:27:53 -0000 Received: from mail.saionline.com (root@206.101.79.2) by egcs.cygnus.com with SMTP; 13 Aug 1999 22:27:53 -0000 Received: from plaid_build (fwuser@nic.saionline.com [206.101.79.10]) by mail.saionline.com (8.8.7/8.8.5) with SMTP id RAA18197 for ; Fri, 13 Aug 1999 17:15:28 -0500 Message-ID: <001f01bee5db$16666380$5a02a8c0@plaid_build.saionline.com> From: "Vijay" To: Subject: Details on binutils/gas/ld Date: Fri, 13 Aug 1999 17:27:54 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01BEE5B1.2D5F6070" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 This is a multi-part message in MIME format. ------=_NextPart_000_001C_01BEE5B1.2D5F6070 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am having major problems with=20 gcc2.8.1 on solaris 2.6 choking on symbols produced by code like ... .. map > xmap; xmap.insert(make_pair(some_pair)); etc. Basically, i get errors like: usr/ccs/bin/as: "/var/tmp/cc1Ivwu_.s", line 7435: error: can't compute = value of an expression involving an external symbol What may i do? The darned thing compiles fine under VC++ 6.0!! I AM TOLD that gas and the gnu loader will solve this problem. gcc 2.95 = is not yet available for solaris 2.6. So i am looking for detailed instructions on how to=20 1. install gas and the loader for sparc2.6 2. use gas and the gnu loader once it is installed, ie switches etc to = use in gcc 2.8.1 for this purpose? 3. any environment variables i need to set or whatever. thanks very much vijay ------=_NextPart_000_001C_01BEE5B1.2D5F6070 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am having major problems with =
gcc2.8.1 on solaris 2.6 choking on = symbols=20 produced by code like
 
...
..
map<string, = map<string,string> >=20 xmap;
 
xmap.insert(make_pair(some_pair));
 
etc.
 
Basically, i get errors like:
usr/ccs/bin/as: = "/var/tmp/cc1Ivwu_.s",=20 line 7435: error: can't compute value of an expression involving an = external=20 symbol
 
What may i do? The darned = thing compiles=20 fine under VC++ 6.0!!
 
I AM TOLD that gas and the = gnu loader=20 will solve this problem. gcc 2.95 is not yet available for solaris=20 2.6.
So i am looking for = detailed=20 instructions on how to
 
1.  install gas and = the loader for=20 sparc2.6
2.  use gas and the = gnu loader once=20 it is installed, ie switches etc to use in gcc 2.8.1 for this=20 purpose?
3. any environment variables i need to set or whatever.
 
thanks very much
 
vijay
------=_NextPart_000_001C_01BEE5B1.2D5F6070-- From gcc-return-9100-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 14 03:19:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6630 invoked by alias); 14 Aug 1999 03:19:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6612 invoked from network); 14 Aug 1999 03:19:42 -0000 Received: from ftp.itms.com (HELO ns.itms.com) (12.3.142.6) by egcs.cygnus.com with SMTP; 14 Aug 1999 03:19:42 -0000 Received: from itms.com (vty4.dac.net [207.198.249.14]) by ns.itms.com (8.8.7/8.8.7) with ESMTP id AAA13956 for ; Sat, 14 Aug 1999 00:24:23 -0400 Message-ID: <37B4DD84.DF4BA86D@itms.com> Date: Fri, 13 Aug 1999 23:07:48 -0400 From: Craig Hutchison Organization: In-Touch Management Systems X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: gcc 2.95 build success Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I successfully built gcc-2.95 for "i486-pc-linux-gnu". *NOTE: Using Slackware 3.6 I had to upgrade from libc-5.4.46 to glibc2.0.7 before it would compile. Bye From gcc-return-9101-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 14 06:58:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15674 invoked by alias); 14 Aug 1999 06:58:53 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15659 invoked from network); 14 Aug 1999 06:58:51 -0000 Received: from smtp01.highway.ne.jp (210.166.100.60) by egcs.cygnus.com with SMTP; 14 Aug 1999 06:58:51 -0000 Received: from 210.166.108.50 (x53-050.atsuta.highway.ne.jp [210.166.108.50]) by smtp01.highway.ne.jp (8.9.3/3.7W99080410) with SMTP id PAA11885 for ; Sat, 14 Aug 1999 15:58:48 +0900 (JST) Message-Id: <19990814155841.Postino-028977@smtp01.highway.ne.jp> Date: Sat, 14 Aug 1999 15:58:41 +0900 To: gcc@gcc.gnu.org From: Kaoru Fukui Subject: I cannot use glibc-2.1.2 compiled by gcc-2.95.1 X-Mailer: PostinoClassic Version 1.3 PPC X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Thanks,your great works. I have success rebuilding gcc-2.95.1 from cvs. Some usally application compiled successfull. Then i could rebuild glibc-2.1.2 with gcc-2.95.1. But I cannot use the glibc which is rebuild with gcc-2.95.1, so I try to rebuild the same sourve of glibc-2.1.2 with egcs-1.1.2 again. It's no problem,good all. My first system is glibc-2.1.2 which is rebuilt egcs-1.1.2 and binutils is binutils-2.9.5.0.6 it's also rebuilt egcs-1.1.2, so I installed gcc-2.95. My machine is powerpc MkLinux-R1. But I couldn't get good using new rebuilt glibc. I show the error rpm -iUvh glibc* glibc ################## glibc-devel ############## /sbin/install-info: error in loading shared libraries: /sbin/install-info: symbol __register_frame_info,version GLIBC_2.0 not defined in file libc.so.6 with link time reference. execution of script failed glibc-profile ############# Any suggestion? Kaoru Fukui Thanks From gcc-return-9102-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 14 08:55:23 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30207 invoked by alias); 14 Aug 1999 08:55:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30192 invoked from network); 14 Aug 1999 08:55:18 -0000 Received: from rtl.cygnus.com (HELO gluttony.geoffk.wattle.id.au) (205.180.230.21) by egcs.cygnus.com with SMTP; 14 Aug 1999 08:55:18 -0000 Received: (from geoffk@localhost) by gluttony.geoffk.wattle.id.au (8.9.3/8.9.3) id SAA00875; Sat, 14 Aug 1999 18:55:25 +1000 To: egcs@gcc.gnu.org Subject: Re: I cannot use glibc-2.1.2 compiled by gcc-2.95.1 References: <19990814155841.Postino-028977@smtp01.highway.ne.jp> From: Geoff Keating In-Reply-To: Kaoru Fukui's message of "Sat, 14 Aug 1999 15:58:41 +0900" X-Mailer: Gnus v5.5/Emacs 20.3 Date: 14 Aug 1999 18:55:23 +1000 Message-ID: Lines: 43 Kaoru Fukui writes: > I have success rebuilding gcc-2.95.1 from cvs. > Some usally application compiled successfull. > > Then i could rebuild glibc-2.1.2 with gcc-2.95.1. > > But I cannot use the glibc which is rebuild with gcc-2.95.1, > so I try to rebuild the same sourve of glibc-2.1.2 with egcs-1.1.2 again. > It's no problem,good all. > > My first system is glibc-2.1.2 which is rebuilt egcs-1.1.2 and binutils is > binutils-2.9.5.0.6 it's also rebuilt egcs-1.1.2, so I installed gcc-2.95. > My machine is powerpc MkLinux-R1. > /sbin/install-info: error in loading shared libraries: /sbin/install-info: > symbol __register_frame_info,version GLIBC_2.0 not defined in file libc.so.6 > with link time reference. > Any suggestion? Please read the glibc FAQ before attempting to install it. Part of it says: {GK} On some Linux distributions for PowerPC, you can see this when you have built gcc or egcs from the Web sources (gcc versions 2.95 or earlier), then re-built glibc. This happens because in these versions of gcc, exception handling is implemented using an older method; the people making the distributions are a little ahead of their time. A quick solution to this is to find the libgcc.a file that came with the distribution (it would have been installed under /usr/lib/gcc-lib), do `ar x libgcc.a frame.o' to get the frame.o file out, and add a line saying `LDLIBS-c.so += frame.o' to the file `configparms' in the directory you're building in. You can check you've got the right `frame.o' file by running `nm frame.o' and checking that it has the symbols defined that you're missing. This will let you build glibc with the C compiler. The C++ compiler will still be binary incompatible with any C++ shared libraries that you got with your distribution. -- Geoffrey Keating From gcc-return-9103-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 14 09:55:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3972 invoked by alias); 14 Aug 1999 09:55:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3956 invoked from network); 14 Aug 1999 09:54:54 -0000 Received: from linuxpc1.lauterbach.com (qmailr@194.195.165.177) by egcs.cygnus.com with SMTP; 14 Aug 1999 09:54:54 -0000 Received: (qmail 21239 invoked from network); 14 Aug 1999 09:54:49 -0000 Received: from ns1226.munich.netsurf.de (HELO ns1102.munich.netsurf.de) (195.180.235.226) by linuxpc1 with SMTP; 14 Aug 1999 09:54:49 -0000 From: Franz Sirl To: Geoff Keating , gcc@gcc.gnu.org Subject: Re: I cannot use glibc-2.1.2 compiled by gcc-2.95.1 Date: Sat, 14 Aug 1999 11:47:31 +0200 X-Mailer: KMail [version 1.0.27] Content-Type: text/plain References: <19990814155841.Postino-028977@smtp01.highway.ne.jp> In-Reply-To: Cc: Kaoru Fukui MIME-Version: 1.0 Message-Id: <99081411552100.00493@ns1102.munich.netsurf.de> Content-Transfer-Encoding: 8bit Am Sam, 14 Aug 1999 schrieb Geoff Keating: >Kaoru Fukui writes: > >> I have success rebuilding gcc-2.95.1 from cvs. >> Some usally application compiled successfull. >> >> Then i could rebuild glibc-2.1.2 with gcc-2.95.1. >> >> But I cannot use the glibc which is rebuild with gcc-2.95.1, >> so I try to rebuild the same sourve of glibc-2.1.2 with egcs-1.1.2 again. >> It's no problem,good all. >> >> My first system is glibc-2.1.2 which is rebuilt egcs-1.1.2 and binutils is >> binutils-2.9.5.0.6 it's also rebuilt egcs-1.1.2, so I installed gcc-2.95. >> My machine is powerpc MkLinux-R1. > >> /sbin/install-info: error in loading shared libraries: /sbin/install-info: >> symbol __register_frame_info,version GLIBC_2.0 not defined in file libc.so.6 >> with link time reference. > >> Any suggestion? > >Please read the glibc FAQ before attempting to install it. Part of it says: > >{GK} On some Linux distributions for PowerPC, you can see this when you have >built gcc or egcs from the Web sources (gcc versions 2.95 or earlier), then >re-built glibc. This happens because in these versions of gcc, exception >handling is implemented using an older method; the people making the >distributions are a little ahead of their time. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Nice way to state the situation :-). At the time this was decided egcs-1.2 was scheduled to include DWARF EH and we wanted to avoid another major binary breakage just after people have been in the R4->R5 hell. Unfortunately, due to some misunderstandings, it didn't make it into gcc-2.95 (aka egcs-1.2) :-(. The patch to bring DWARF EH for PPC to gcc-2.95.1 can be found at . Franz. From gcc-return-9104-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 14 17:28:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10595 invoked by alias); 14 Aug 1999 17:28:12 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10575 invoked from network); 14 Aug 1999 17:27:55 -0000 Received: from server.col.psi.br (@200.203.189.130) by egcs.cygnus.com with SMTP; 14 Aug 1999 17:27:55 -0000 Received: (qmail 5094 invoked by alias); 14 Aug 1999 14:30:44 -0000 Received: (qmail 5088 invoked from network); 14 Aug 1999 14:30:44 -0000 Received: from beta.col.psi.br (HELO opensystem.org.br) (root@10.0.0.2) by ana.col.psi.br with SMTP; 14 Aug 1999 14:30:44 -0000 Message-ID: <37B57CF2.58701843@opensystem.org.br> Date: Sat, 14 Aug 1999 14:28:02 +0000 From: Leonardo Marques de Souza Reply-To: leo@opensystem.org.br Organization: GU X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-ac2 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: GCC 2.95 x Kernel 2.2.11-ac2 Opt. 'Problems' with RAID ??? References: <199908141311.JAA14317@gsxr.pajato.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have some doubts about optimizations with gcc-2.95. After install the new gcc over RedHat6.0(very clean install) and upgraded to kernel 2.2.11-ac2, i tryed to compile the new kernel with more 'optimizations' (modifying the arch/i386/Makefile): first test (without any touch in CFLAGS arqs..) my Machine is K6-2 333MHz... DEFAULT in Makefile ( -m486 -O2) i got this (the new raid patch apeer in Alan coxs patchs - ac) Aug 14 05:46:07 carol kernel: pII_mmx : 734.949 MB/sec Aug 14 05:46:07 carol kernel: p5_mmx : 711.708 MB/sec Aug 14 05:46:07 carol kernel: 8regs : 496.824 MB/sec Aug 14 05:46:07 carol kernel: 32regs : 309.753 MB/sec Aug 14 05:46:07 carol kernel: using fastest function: pII_mmx (734.949 MB/sec) After modify to -O9 -march=k6 i got Aug 14 06:07:10 carol kernel: hda: QUANTUM FIREBALL EL5.1A, 4892MB w/418kB Cache, CHS=623/255/63 Aug 14 06:07:10 carol kernel: pII_mmx : 717.423 MB/sec Aug 14 06:07:10 carol kernel: p5_mmx : 684.657 MB/sec Aug 14 06:07:10 carol kernel: 8regs : 470.916 MB/sec Aug 14 06:07:10 carol kernel: 32regs : 332.613 MB/sec After change it to -O9 -mpentium i got: Aug 15 00:23:08 carol kernel: hda: QUANTUM FIREBALL EL5.1A, 4892MB w/418kB Cache, CHS=623/255/63 Aug 15 00:23:08 carol kernel: pII_mmx : 711.708 MB/sec Aug 15 00:23:08 carol kernel: p5_mmx : 685.038 MB/sec Aug 15 00:23:08 carol kernel: 8regs : 470.916 MB/sec Aug 15 00:23:08 carol kernel: 32regs : 322.326 MB/sec Why its happen?? the GCC compiler make the Raid analiser some 'confused' and optimizations really happen or its a really strange optimizations with RAID causing to 'downgrade' with -m486 and -march=k6 or -mpentium .... I would like to understand that...(if exists any solutions.. are very wellcome!!! but i would like to understand only...) HOoo yes!! my kernel are running very well, without _anY_ problem or fault... thats grate!!! Why the Kernel guys do not make new Optimizations Flags in kernel source??? if is to discover new bugs in kernel/gcc, the must thing are change this flags to make kernel more fast!! (but , of course, if happen any problem... do a any options to do 'default' flags to worste case... like '-O -g -m386 -fno-softmath.. and so on...) Thanks in advanced... T+ Leo From gcc-return-9105-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 14 22:02:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29028 invoked by alias); 14 Aug 1999 22:02:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29013 invoked from network); 14 Aug 1999 22:02:31 -0000 Received: from sdn-ar-002camontp284.dialsprint.net (HELO newamerica.org) (158.252.196.214) by egcs.cygnus.com with SMTP; 14 Aug 1999 22:02:31 -0000 From: To: Date: Sat, 14 Aug 1999 11:40:17 Message-Id: <844.763886.887392@newamerica.org> Subject: This is unsolicited email (example). Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The UEAT would make your email address unlisted.It will permanently REMOVE your address from all mailing lists (no more spam),as well as automatically searching for products/people (alternative for search engines & news groups). Please contact your ISP,you should get the UEAT free of charge. This is the last unsolicited email you would ever receive from us.You not need to request to be REMOVE. Details at: (www. syndicate) HTTP://NewAmerica.org/ From gcc-return-9106-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 14 23:14:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32297 invoked by alias); 14 Aug 1999 23:14:15 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32274 invoked from network); 14 Aug 1999 23:14:13 -0000 Received: from caip.rutgers.edu (128.6.236.10) by egcs.cygnus.com with SMTP; 14 Aug 1999 23:14:13 -0000 Received: (from ghazi@localhost) by caip.rutgers.edu (8.9.3/8.9.3) id TAA17260; Sat, 14 Aug 1999 19:14:11 -0400 (EDT) Date: Sat, 14 Aug 1999 19:14:11 -0400 (EDT) From: "Kaveh R. Ghazi" Message-Id: <199908142314.TAA17260@caip.rutgers.edu> To: rth@cygnus.com Subject: Re: What should -Wmissing-noreturn do with "int main(){exit(0);}" ? Cc: egcs-patches@egcs.cygnus.com, egcs@egcs.cygnus.com > From: Richard Henderson > > On Thu, Aug 12, 1999 at 03:02:02PM -0400, Kaveh R. Ghazi wrote: > > > int main() { exit(0); } > > > > foo.c: In function `main': > > foo.c:1: warning: function might be possible candidate for > > attribute `noreturn' > > > > The diagnostic is technically correct, but perhaps it should do > > something different here. I see two alternatives. > > Since the diag is correct, is there any need to change it at all? > I don't see any reason to... > r~ Well think about what one would need to do to silence the warning. Is it useful to declare `main' as noreturn? Attribute noreturn provides two benefits, a slight optimization, and better analysis for things like unused variables. But if I understand things correctly, these benefits are for *callers* of the noreturn function. And the attribute must seen by the callers, which won't happen for `main'. So I think -Wmissing-noreturn should either ignore `main', or if it detects `main' is noreturn it should suggest the user switch from exitting out of `main' to issuing a return from `main'. I.e.: "main(){exit(0);}" -> "main(){return 0;}". I still favor having it ignore main, but either way it didn't seem logical for the compiler to suggest declaring main as noreturn. --Kaveh PS: Here's what I had in mind, what do you think? 1999-08-12 Kaveh R. Ghazi * c-decl.c (finish_function): Ignore "main" when checking for -Wmissing-noreturn functions. * invoke.texi: Document it. diff -rup orig/egcs-CVS19990811/gcc/c-decl.c egcs-CVS19990811/gcc/c-decl.c --- orig/egcs-CVS19990811/gcc/c-decl.c Mon Aug 9 15:41:49 1999 +++ egcs-CVS19990811/gcc/c-decl.c Thu Aug 12 15:34:34 1999 @@ -6890,7 +6890,8 @@ finish_function (nested) if (warn_missing_noreturn && !TREE_THIS_VOLATILE (fndecl) && !current_function_returns_null - && !current_function_returns_value) + && !current_function_returns_value + && strcmp (IDENTIFIER_POINTER (DECL_NAME (fndecl)), "main")) warning ("function might be possible candidate for attribute `noreturn'"); if (TREE_THIS_VOLATILE (fndecl) && current_function_returns_null) diff -rup orig/egcs-CVS19990811/gcc/invoke.texi egcs-CVS19990811/gcc/invoke.texi --- orig/egcs-CVS19990811/gcc/invoke.texi Wed Aug 11 07:42:14 1999 +++ egcs-CVS19990811/gcc/invoke.texi Thu Aug 12 15:40:09 1999 @@ -1759,8 +1760,10 @@ header files. Warn about functions which might be candidates for attribute @code{noreturn}. Note these are only possible candidates, not absolute ones. Care should be taken to manually verify functions actually do not ever return before -adding the @code{noreturn} attribute, otherwise subtle code generation -bugs could be introduced. +adding the @code{noreturn} attribute. Otherwise, subtle code generation +bugs could be introduced. This warning is ignored for function @samp{main} +because it is common practice to call @samp{exit} from there rather +than using @code{return} statements. @item -Wredundant-decls Warn if anything is declared more than once in the same scope, even in 1999-08-12 Kaveh R. Ghazi * gcc.dg/noreturn-1.c: Test "main" as a special case. diff -rup orig/egcs-CVS19990811/gcc/testsuite/gcc.dg/noreturn-1.c egcs-CVS19990811/gcc/testsuite/gcc.dg/noreturn-1.c --- orig/egcs-CVS19990811/gcc/testsuite/gcc.dg/noreturn-1.c Thu May 13 12:15:13 1999 +++ egcs-CVS19990811/gcc/testsuite/gcc.dg/noreturn-1.c Thu Aug 12 15:41:07 1999 @@ -41,3 +41,9 @@ foo6(void) { return; } /* { dg-bogus "warning:" "this function should not get any warnings" } */ + +int +main() +{ + exit(0); +} /* { dg-bogus "warning:" "this function should not get any warnings" } */ -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions From gcc-return-9107-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 15 05:04:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13676 invoked by alias); 15 Aug 1999 05:04:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13659 invoked from network); 15 Aug 1999 05:04:03 -0000 Received: from avocet.prod.itd.earthlink.net (207.217.121.50) by egcs.cygnus.com with SMTP; 15 Aug 1999 05:04:03 -0000 Received: from earthlink.net (sdn-ar-003casfrMP094.dialsprint.net [158.252.210.96]) by avocet.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id WAA18695; Sat, 14 Aug 1999 22:03:48 -0700 (PDT) Message-ID: <37B64BE1.76D3C98D@earthlink.net> Date: Sat, 14 Aug 1999 22:10:58 -0700 From: Michael Gordon Weaver Reply-To: weaver@ieee.org X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Franz Sirl CC: weaver@ieee.org, gcc@gcc.gnu.org Subject: Re: gcc2.95 installed References: <4.2.0.58.19990813183422.03fc9f00@mail.lauterbach.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Thanks for the information. I got version 2.9.5.0.6 of binutils, and was able to build gcc2.95 for powerpc-unknown-linux-gnulibc1 without a hitch. If someone reading this could update the web page for system specific instructions for installing gcc2.95 on powerpc-linux to mention binutils version 2.9.4.0.8 instead of 2.9.1.0.23, I would appreciate it. Michael. Franz Sirl wrote: > At 10:15 13.08.99 , Michael Gordon Weaver wrote: > >I have built and installed gcc2.95 on my system: > > > >powerpc-unknown-linux-gnulibc1 > > > >Besides installing the lastest version of binutils as recommended, > >I had to make a change to the file: > > > >gcc/config/rs6000/linux.h > > > >at line 39 to change '-m elf32ppclinux' to '-m elf32ppc'. > >This appears to be a flag passed to 'ld', and the version > >of gld I have recognizes '-m elf32ppc' but not '-m elf32ppclinux'. > > You need binutils-2.9.4.0.8 or newer on Linux/PPC. You can grab it from > . > > Franz. From gcc-return-9108-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 15 07:47:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19284 invoked by alias); 15 Aug 1999 07:47:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19267 invoked from network); 15 Aug 1999 07:47:20 -0000 Received: from brandx.net (root@209.55.64.14) by egcs.cygnus.com with SMTP; 15 Aug 1999 07:47:20 -0000 Received: from pobox.com (DSL82-091.brandx.net [209.55.82.91]) by brandx.net (8.8.8/8.8.8) with ESMTP id AAA11647 for ; Sun, 15 Aug 1999 00:58:00 -0700 (PDT) Message-ID: <37B67040.CAA6547C@pobox.com> Date: Sun, 15 Aug 1999 00:46:08 -0700 From: Paul Burchard X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: surprising optimization results Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Inlines which call and return by value (even struct value) are showing up consistently faster in my tests than the equivalent inlines which call and return using non-const reference args (gcc configuration below). Assuming this is a real effect, it is surprising to me -- but perhaps not to those more familiar with gcc's optimization strategies (maybe by-value makes alias analysis easier?). Any insight into tuning my code for gcc-optimizability is appreciated... Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95/specs gcc version 2.95 19990728 (release) /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95/cpp -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__EXCEPTIONS -D__OPTIMIZE__ -Wall -Winline -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di686 -Dpentiumpro -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ -DNO_EXPORT test2.cc /tmp/ccOTW7Ie.ii GNU CPP version 2.95 19990728 (release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95/../../../../include/g++-3 /usr/local/include /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95/../../../../i686-pc-linux-gnu/include /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95/include /usr/include End of search list. The following default directories have been omitted from the search path: End of omitted list. /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95/cc1plus /tmp/ccOTW7Ie.ii -quiet -dumpbase test2.cc -O6 -Wall -Winline -version -o /tmp/ccn8UCEj.s GNU C++ version 2.95 19990728 (release) (i686-pc-linux-gnu) compiled by GNU C version 2.95 19990728 (release). as -V -Qy -o /tmp/ccJsJaNt.o /tmp/ccn8UCEj.s GNU assembler version 2.9.1 (i386-redhat-linux), using BFD version 2.9.1.0.23 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95/collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95/crtbegin.o -L/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95 -L/usr/local/lib /tmp/ccJsJaNt.o -lstdc++ -lgcc -lc -lgcc /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95/crtend.o /usr/lib/crtn.o -- ---------------------------------------------------------------------- Paul Burchard http://www.pobox.com/~burchard/ ---------------------------------------------------------------------- From gcc-return-9109-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 15 07:56:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21027 invoked by alias); 15 Aug 1999 07:56:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21012 invoked from network); 15 Aug 1999 07:56:52 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 15 Aug 1999 07:56:52 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id EAA10776; Sun, 15 Aug 1999 04:52:43 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id EAA28370; Sun, 15 Aug 1999 04:52:41 -0300 (EST) To: chandra Cc: gcc@gcc.gnu.org Subject: Re: Gcc Fails during ld phase for automatic instantiation References: <37B476EA.BE7DDB1F@us.oracle.com> From: Alexandre Oliva Date: 15 Aug 1999 04:56:35 -0300 In-Reply-To: chandra's message of "Fri, 13 Aug 1999 12:50:02 -0700" Message-ID: Lines: 15 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 13, 1999, chandra wrote: > I Compiled template-using code with `-frepo'. The > compiler generated files with the extension `.rpo' listing all of > the template instantiations . But when I try to create the final > executable I see lot of undefined reference. Are templates defined (not only declared) in all translation units that use them? This is required even when using -frepo. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9110-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 15 08:03:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21955 invoked by alias); 15 Aug 1999 08:03:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21936 invoked from network); 15 Aug 1999 08:03:05 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 15 Aug 1999 08:03:05 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id EAA10786; Sun, 15 Aug 1999 04:58:51 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id EAA28447; Sun, 15 Aug 1999 04:58:51 -0300 (EST) To: "Vijay" Cc: Subject: Re: Details on binutils/gas/ld References: <001f01bee5db$16666380$5a02a8c0@plaid_build.saionline.com> From: Alexandre Oliva Date: 15 Aug 1999 05:02:44 -0300 In-Reply-To: "Vijay"'s message of "Fri, 13 Aug 1999 17:27:54 -0500" Message-ID: Lines: 41 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 13, 1999, "Vijay" wrote: > gcc2.8.1 on solaris 2.6 choking on symbols produced by code like > map > xmap; > xmap.insert(make_pair(some_pair)); > usr/ccs/bin/as: "/var/tmp/cc1Ivwu_.s", line 7435: error: can't compute value of an expression involving an external symbol That's usually because the assembler can't deal with the long mangled names produced by gcc. See http://egcs.cygnus.com/faq.html#squangle > What may i do? The darned thing compiles fine under VC++ 6.0!! It also compiles fine with gcc. The only problem is the assembler, that the compiler implicitly runs for you. > I AM TOLD that gas and the gnu loader will solve this problem. Yup. In fact, you only need gas, but since you can get both at the same time, why not? :-) > gcc 2.95 is not yet available for solaris 2.6. Huh? Of course it is. You can even use the gcc 2.8.1 you've got to build gcc 2.95 on Solaris 2.6. > 1. install gas and the loader for sparc2.6 Get GNU binutils from ftp.gnu.org or see http://egcs.cygnus.com/faq.html#x86eh > 2. use gas and the gnu loader once it is installed, ie switches etc to use in gcc 2.8.1 for this purpose? See http://egcs.cygnus.com/faq.html#gas -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9111-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 15 18:14:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7387 invoked by alias); 15 Aug 1999 18:14:16 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7275 invoked from network); 15 Aug 1999 18:14:05 -0000 Received: from 209-249-66-150.snj0.flashcom.net (HELO ocean.lucon.org) (postfix@209.249.66.150) by egcs.cygnus.com with SMTP; 15 Aug 1999 18:14:05 -0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 033B657BA; Sun, 15 Aug 1999 11:14:03 -0700 (PDT) Subject: binutils 2.9.5.0.7 is released. To: linux-gcc@vger.rutgers.edu (linuxgcc) Date: Sun, 15 Aug 1999 11:14:03 -0700 (PDT) Cc: kjahds@kjahds.com (Kenneth Albanowski), lmfken@lmf.ericsson.se (Kenneth Osterberg), mat@lcs.mit.edu (Mat Hostetter), doughera@lafcol.lafayette.edu (Andy Dougherty), brian@mathworks.com (Brian Bourgault), imp@village.org (Warner Losh), meissner@cygnus.com (Michael Meissner), rfg@monkeys.com (Ron Guilmette), linux-binutils-in@polstra.com (John Polstra), galenh@micron.net (Galen Hazelwood), ralf@informatik.uni-koblenz.de (Ralf Baechle), linas@linas.org (Linas Vepstas), aries@hal2000.terra.vein.hu (Feher Janos), libc-hacker@sourceware.cygnus.com (GNU C Library), egcs@egcs.cygnus.com X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990815181403.033B657BA@ocean.lucon.org> From: hjl@lucon.org (H.J. Lu) Hi, Ralf, You can send me MIPS patches when you are ready. In the meantime, I'd like to start testing on other archs. Thanks. H.J. --- This is the beta release of binutils 2.9.5.0.7 for Linux, which is based on binutils 1999 0813 plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.9.5.0.7 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.5.0.7.tar.gz. Source code. 2. binutils-2.9.5.0.6-2.9.5.0.7.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.5.0.7-1.src.rpm. Source RPM. 4. binutils-2.9.5.0.7-1.i386.rpm. X86 inary RPM for RedHat 6.0. 5. binutils-2.9.5.0.7-1.alpha.rpm. Alpha binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils Thanks. H.J. Lu hjl@lucon.org 08/15/99 From gcc-return-9112-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 15 18:34:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9842 invoked by alias); 15 Aug 1999 18:33:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9826 invoked from network); 15 Aug 1999 18:33:40 -0000 Received: from patachou.sti.com.br (200.212.48.251) by egcs.cygnus.com with SMTP; 15 Aug 1999 18:33:40 -0000 Received: from acacio (dial-lc01-14.sti.com.br [200.212.49.14]) by patachou.sti.com.br (8.9.3/8.9.1) with SMTP id PAA27256 for ; Sun, 15 Aug 1999 15:03:29 -0300 Message-ID: <000701bdc877$709f6680$0e31d4c8@acacio> From: "=?iso-8859-1?Q?ac=E1cio_silvestre?=" To: Subject: Linux Programming Date: Sat, 15 Aug 1998 15:06:33 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01BDC85E.4A45A080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BDC85E.4A45A080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please, I am early in Linux programming and I would like to now how I = can set the cursor on text mode. I tried to find a function (in libraries) like = gotoxy, but I didn't. I tried to develope my own function using inline assembly but I don't = now how=20 (in Linux).=20 I hope you can help me. Thank you Ac=E1cio Silvestre - from Brazil =20 ------=_NextPart_000_0004_01BDC85E.4A45A080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 Please, I am early in Linux = programming=20 and I would like to now how I can set the
cursor on text mode. I tried to find = a function=20 (in libraries) like gotoxy, but I didn't.
I tried to develope my own function = using inline=20 assembly but I don't now how
(in Linux).
    I hope you can = help=20 me.
 
          &nbs= p;            = ;            =     =20 Thank you
        &n= bsp;           &nb= sp;           &nbs= p;      =20 Acácio Silvestre - from Brazil
          &nbs= p;=20
------=_NextPart_000_0004_01BDC85E.4A45A080-- From gcc-return-9113-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 15 19:26:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12243 invoked by alias); 15 Aug 1999 19:26:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12207 invoked from network); 15 Aug 1999 19:26:43 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 15 Aug 1999 19:26:43 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA26177; Sun, 15 Aug 1999 12:26:42 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id MAA28699; Sun, 15 Aug 1999 12:26:42 -0700 To: "Kaveh R. Ghazi" Cc: rth@cygnus.com, egcs-patches@egcs.cygnus.com, egcs@egcs.cygnus.com Subject: Re: What should -Wmissing-noreturn do with "int main(){exit(0);}" ? References: <199908142314.TAA17260@caip.rutgers.edu> From: Jason Merrill Date: 15 Aug 1999 12:26:41 -0700 In-Reply-To: "Kaveh R. Ghazi"'s message of "Sat, 14 Aug 1999 19:14:11 -0400 (EDT)" Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Kaveh R Ghazi writes: > Well think about what one would need to do to silence the > warning. Is it useful to declare `main' as noreturn? If it doesn't return, it doesn't return. Calling exit bypasses the return from main. It doesn't make much sense to me, stylistically; I'd suggest changing the exit call to a return statement, but declaring main noreturn would also work. Jason From gcc-return-9114-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 15 19:27:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12667 invoked by alias); 15 Aug 1999 19:27:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12416 invoked from network); 15 Aug 1999 19:27:00 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 15 Aug 1999 19:27:00 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id VAA16287; Sun, 15 Aug 1999 21:24:05 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id VAA01466; Sun, 15 Aug 1999 21:23:35 +0200 Date: Sun, 15 Aug 1999 21:23:35 +0200 Message-Id: <199908151923.VAA01466@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: hackacio@sti.com.br CC: gcc@egcs.cygnus.com In-reply-to: <000701bdc877$709f6680$0e31d4c8@acacio> (hackacio@sti.com.br) Subject: Re: Linux Programming References: <000701bdc877$709f6680$0e31d4c8@acacio> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > Please, I am early in Linux programming and I would like to now how > I can set the cursor on text mode. I tried to find a function (in > libraries) like gotoxy, but I didn't. I tried to develope my own > function using inline assembly but I don't now how (in Linux). I > hope you can help me. Please understand that this list is not the right place for such questions; it is about the C compiler (gcc) only. One of the Linux or Unix usenet groups would be more appropriate. Nevertheless, your question is frequently-asked; you need to study termcap(5) in detail, or the termcap texinfo pages. Hope this helps, Martin From gcc-return-9115-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 15 19:38:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14410 invoked by alias); 15 Aug 1999 19:38:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14393 invoked from network); 15 Aug 1999 19:38:11 -0000 Received: from beowulf.ucsd.edu (kgatlin@132.239.17.2) by egcs.cygnus.com with SMTP; 15 Aug 1999 19:38:11 -0000 Received: (from kgatlin@localhost) by beowulf.ucsd.edu (8.9.1a/8.9.1) id MAA22159 for gcc@gcc.gnu.org; Sun, 15 Aug 1999 12:38:09 -0700 (PDT) Date: Sun, 15 Aug 1999 12:38:09 -0700 (PDT) From: Kang Su Gatlin Message-Id: <199908151938.MAA22159@beowulf.ucsd.edu> To: gcc@gcc.gnu.org Subject: Stack Alignment I'd first like to thank the gcc-2.95 people. I had a code that previously had odd behavior with egcc-2.91 and I suspect it was due to the alignment of doubles on the stack for a Pentium II machine. My question is, what rules did they use to align for the stack on the Pentium II? When I first realized the problem with egcc-2.91 I tried to tweak my code by hand. My original code looked like: { double array[SIZE]; compute(array); } Unfortunately sometimes the data wasn't 8-byte aligned and peformance suffered so I did the following: { double array1[SIZE]; double *array; if((val = ((unsigned long)array1 & 0x7)) != 0) array = (double *)((unsigned long)array1 + 8-val); else array = array1; compute(array); } Surprisingly this gave me uniformly bad performance, although it seems the data was properly aligned. Also with egcc-2.91 using the -malign-double flag seemed to make the code slower. Well I saw that gcc-2.95 was out... installed it and just gave it a shot (with little real hope) and lo and behold... my performance woes were fixed (I could get performance on both of the above codes). While I'm happy with that I'd like to know what I was doing wrong to avoid such a problem again. Thank you, KSG From gcc-return-9116-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 15 20:42:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20259 invoked by alias); 15 Aug 1999 20:42:30 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20244 invoked from network); 15 Aug 1999 20:42:26 -0000 Received: from unknown (HELO server) (209.4.138.251) by egcs.cygnus.com with SMTP; 15 Aug 1999 20:42:26 -0000 From: To: Date: Sun, 15 Aug 1999 13:07:14 Message-Id: <700.571282.337251@server> Subject: Have You Ever Considered ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Have You Ever Considered Starting Your Own Business? If you have; This information may be valuable to you. Question: If you could design an IDEAL Business to go into, would it include any of the following: · Home Based · No Employees · Flexible Hours · Proven Track Record · No Selling Required · Immediate Cash Flow · No Experienced Required · Steady and Unlimited Growth Potential If you answered Yes to any of these questions, then you should consider the Vending Business. The VENDING BUSINESS just passed the $32 BILLION dollar mark, making it the LARGEST ALL CASH BUSINESS IN THE WORLD ! ! ! YES there is BIG MONEY in Vending if you follow a proven system. You have probably seen ads about how to get rich overnight, etc. Well this is NOT a get rich scheme. What we offer is a sensible way to make extra money that could supplement or perhaps even replace your current income. What are company has done is identify those segments of the market that have proven to be the most profitable and have developed new modern equipment to better serve those needs. If you would like to receive a full business package (at no cost to you) on exciting new opportunities in the Vending business: CALL Vendco International, Inc. At: 1-888-954-5950 TODAY. NO Obligation, NO Hassles, NO pressure Be sure to reference code R814C when you call ! ! ! Live representatives are available from 9:00 A.M. to 9:00 P.M. You may leave a message at any other time and a representative will return your call at the time you specify. OR E-mail us at => yesvendco@zipmail.com.br with your name, address, and phone number. Please include ALL of your information and a package will be sent out to you right away. This information is being provided by: Vendco International, Inc. a full service vending company that offers a full range of quality vending equipment directly to the public. IN FULL COMPLIANCE WITH THE LAW This ad is being sent in compliance with the pending Senate bill S. 1618, Title 3, section 301, Paragraph (a)(2)(C) For a current status of pending legislation go to WWW.jmls.edu/cyber/statutes/email/fedtable.html Further transmissions to you by the sender of this email may be stopped.... AT NO COST TO YOU... by clicking here ------> or sending an email to takemeoff@zipmail.com.br and typing in the word "REMOVE" in the subject line. We apologize for any inconvenience. From gcc-return-9117-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 15 21:40:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23346 invoked by alias); 15 Aug 1999 21:40:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23316 invoked from network); 15 Aug 1999 21:40:54 -0000 Received: from smtp1.cern.ch (137.138.128.38) by egcs.cygnus.com with SMTP; 15 Aug 1999 21:40:54 -0000 Received: from pcep-jamie.cern.ch (pcep-jamie.cern.ch [137.138.38.126]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id XAA15869; Sun, 15 Aug 1999 23:40:51 +0200 (MET DST) Received: (from jamie@localhost) by pcep-jamie.cern.ch (8.9.3/8.9.3) id XAA21268; Sun, 15 Aug 1999 23:40:51 +0200 Date: Sun, 15 Aug 1999 23:40:50 +0200 From: Jamie Lokier To: Jason Merrill Cc: "Kaveh R. Ghazi" , rth@cygnus.com, egcs-patches@egcs.cygnus.com, egcs@egcs.cygnus.com Subject: Re: What should -Wmissing-noreturn do with "int main(){exit(0);}" ? Message-ID: <19990815234050.A21258@pcep-jamie.cern.ch> References: <199908142314.TAA17260@caip.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from Jason Merrill on Sun, Aug 15, 1999 at 12:26:41PM -0700 Jason Merrill wrote: > If it doesn't return, it doesn't return. Calling exit bypasses the return > from main. It doesn't make much sense to me, stylistically; I'd suggest > changing the exit call to a return statement, but declaring main noreturn > would also work. Exiting makes a lot of sense to me. Do you want main full of returns while other code uses exit for the same thing? If there were such a thing as enum exit_status_t, maybe, but there isn't so return invites a few bugs when cutting & pasting. -- Jamie From gcc-return-9118-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 00:08:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1346 invoked by alias); 16 Aug 1999 00:08:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1327 invoked from network); 16 Aug 1999 00:08:16 -0000 Received: from unidui.uni-duisburg.de (134.91.4.3) by egcs.cygnus.com with SMTP; 16 Aug 1999 00:08:16 -0000 Received: from d250-hrz.uni-duisburg.de (sg618lo@d250-hrz.uni-duisburg.de [134.91.4.15]) by unidui.uni-duisburg.de (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id CAA03394 for ; Mon, 16 Aug 1999 02:07:44 +0200 (METDST) Received: (from sg618lo@localhost) by d250-hrz.uni-duisburg.de (8.8.6 (PHNE_14041)/8.7.3) id CAA03753 for egcs@egcs.cygnus.com; Mon, 16 Aug 1999 02:07:43 +0200 (MESZ) From: Christian Loth Message-Id: <199908160007.CAA03753@d250-hrz.uni-duisburg.de> Subject: 2d-arrays with classes no longer legal? To: egcs@egcs.cygnus.com Date: Mon, 16 Aug 1999 02:07:43 +0200 (MESZ) X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit -- Christian Loth Coder of 'Project Gidayu' Computer Science Student, University of Dortmund sg618lo@uni-duisburg.de - chloth00@marvin.cs.uni-dortmund.de From gcc-return-9119-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 00:23:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2679 invoked by alias); 16 Aug 1999 00:23:01 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2658 invoked from network); 16 Aug 1999 00:22:58 -0000 Received: from unidui.uni-duisburg.de (134.91.4.3) by egcs.cygnus.com with SMTP; 16 Aug 1999 00:22:58 -0000 Received: from d250-hrz.uni-duisburg.de (sg618lo@d250-hrz.uni-duisburg.de [134.91.4.15]) by unidui.uni-duisburg.de (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id CAA03654 for ; Mon, 16 Aug 1999 02:22:30 +0200 (METDST) Received: (from sg618lo@localhost) by d250-hrz.uni-duisburg.de (8.8.6 (PHNE_14041)/8.7.3) id CAA03803 for egcs@egcs.cygnus.com; Mon, 16 Aug 1999 02:22:29 +0200 (MESZ) From: Christian Loth Message-Id: <199908160022.CAA03803@d250-hrz.uni-duisburg.de> Subject: Sorry - message body was missing *blush* To: egcs@egcs.cygnus.com Date: Mon, 16 Aug 1999 02:22:29 +0200 (MESZ) X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Greetings, Recently I have test-installed gcc 2.95 and compiled a medium project (as of writing ~16k lines of code) with it. Now, I stumbled across an error, where egcs 1.1.2 compiled flawlessly. The critical code is: const string &elf::speaksLike(tongue_mode _tm) { static const string speak_modes[3][3] = { { "ask", "exclaim", "say" }, { "intone", "chant", "melodically say" }, { "sweetly inquire", "emote", "sing" } }; return speak_modes[whatGender()][_tm]; } tongue_mode is the following enumeration: enum tongue_mode { tm_question, tm_exclaim, tm_sentence }; and whatGender() returns the following enumeration: enum c_gender { neutral, male, female }; Now, compiling the above gives the following errormessages with gcc 2.95: elf.cc: In method `const class string & elf::speaksLike(tongue_mode)': elf.cc:61: conversion from `const basic_string,__default_alloc_template >[3]' to non-scalar type `basic_string,__default_alloc_template >' requested elf.cc:61: conversion from `const basic_string,__default_alloc_template >[3]' to non-scalar type `basic_string,__default_alloc_template >' requested elf.cc:61: conversion from `const basic_string,__default_alloc_template >[3]' to non-scalar type `basic_string,__default_alloc_template >' requested Now my question: is this a (known?) bug with gcc 2.95, or is the above code not conforming to the C++ Standard? - Chris -- Christian Loth Coder of 'Project Gidayu' Computer Science Student, University of Dortmund sg618lo@uni-duisburg.de - chloth00@marvin.cs.uni-dortmund.de From gcc-return-9120-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 02:45:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13469 invoked by alias); 16 Aug 1999 02:45: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13445 invoked from network); 16 Aug 1999 02:45:41 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 16 Aug 1999 02:45:41 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id UAA20267; Sun, 15 Aug 1999 20:42:12 -0600 X-Mailer: exmh version 2.0.2 To: Kang Su Gatlin cc: gcc@gcc.gnu.org Subject: Re: Stack Alignment Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 15 Aug 1999 12:38:09 PDT. <199908151938.MAA22159@beowulf.ucsd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Aug 1999 20:42:12 -0600 Message-ID: <20264.934771332@upchuck.cygnus.com> From: Jeffrey A Law In message <199908151938.MAA22159@beowulf.ucsd.edu>you write: > I'd first like to thank the gcc-2.95 people. I had a code that previously > had odd behavior with egcc-2.91 and I suspect it was due to the alignment > of doubles on the stack for a Pentium II machine. My question is, > what rules did they use to align for the stack on the Pentium II? Quite likely. The ABI used for x86 machines only requires doubles to be 4 byte aligned, and earlier versions of gcc made no special effort to provide more alignment for doubles. > Well I saw that gcc-2.95 was out... installed it and just gave it a > shot (with little real hope) and lo and behold... my performance woes > were fixed (I could get performance on both of the above codes). > While I'm happy with that I'd like to know what I was doing wrong to > avoid such a problem again. gcc-2.95 *attempts* to keep the stack aligned to a 16 byte boundary and to align doubles on their natural boundary. If you ever run into a case where gcc-2.95 does not preserve stack alignment or a case where a double is not aligned to at least an 8 byte boundary we would like to see the code so that we can fix it. jeff From gcc-return-9121-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 03:18:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16044 invoked by alias); 16 Aug 1999 03:18:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16029 invoked from network); 16 Aug 1999 03:18:38 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 16 Aug 1999 03:18:38 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with SMTP id XAA24107 for ; Sun, 15 Aug 1999 23:18:32 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com by world.std.com (TheWorld/Spike-2.0) id AA26220; Sun, 15 Aug 1999 23:16:08 -0400 Received: (qmail 16508 invoked by uid 500); 15 Aug 1999 23:21:21 -0000 Date: 15 Aug 1999 23:21:20 -0000 Message-Id: <19990815232120.16507.qmail@deer> To: kgatlin@cs.ucsd.edu Cc: gcc@gcc.gnu.org Cc: craig@jcb-sc.com In-Reply-To: <199908151938.MAA22159@beowulf.ucsd.edu> (message from Kang Su Gatlin on Sun, 15 Aug 1999 12:38:09 -0700 (PDT)) Subject: Re: Stack Alignment References: <199908151938.MAA22159@beowulf.ucsd.edu> >Unfortunately sometimes the data wasn't 8-byte aligned and peformance >suffered so I did the following: >{ > double array1[SIZE]; > double *array; > if((val = ((unsigned long)array1 & 0x7)) != 0) > array = (double *)((unsigned long)array1 + 8-val); > else > array = array1; > compute(array); >} > >Surprisingly this gave me uniformly bad performance, although it >seems the data was properly aligned. Also with egcc-2.91 using the >-malign-double flag seemed to make the code slower. That can't be the code you used, because `val' is undeclared. Further, while `compute' might indeed have received aligned pointers, it might have been getting an array one element shorter than `SIZE', so who knows what "performance" problems might have resulted from that bug. So, in a case like this, where you want a pointer to the first or second half element of an allocated array to achieve the alignment you want, you need to allocate *one* more element (to make the second-half-element case work) than you'd normally need. I.e. use `double array1[SIZE+1]'. Also, it's usually faster to not bother testing than to test so as to save an integer add and boolean AND operation. Though that probably wouldn't explain performance problems you were seeing, I've normally used code like: array = (double *) ((((offset_t) array1) + 0x4) & ~(offset_t) 0x7) (Maybe `offset_t' isn't the right type to use...though portability is less of a concern for code like this, make sure you don't cause the code to break anywhere that a straight `array = array1;' would work. Also, I prefer parenthesizing to expecting the reader to remember whether a cast has higher precedence than `+', etc. Don't trust my code, just use it to get an idea of how to avoid the `if'.) Finally, though, it might be the case that 2.95 is giving you better than 64-bit alignment and that's needed for the processor you're using. It really should be the compiler/linker/loader/OS that ensure reasonable default alignment for data in inner loops, rather than the user's code, given the proliferation of chips with different performance characteristics. Of course, reality is different from the ideal.... tq vm, (burley) From gcc-return-9122-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 06:16:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26504 invoked by alias); 16 Aug 1999 06:16:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26488 invoked from network); 16 Aug 1999 06:16:07 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 16 Aug 1999 06:16:07 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id AAA20743; Mon, 16 Aug 1999 00:13:00 -0600 X-Mailer: exmh version 2.0.2 To: weaver@ieee.org cc: Franz Sirl , gcc@gcc.gnu.org Subject: Re: gcc2.95 installed Reply-To: law@cygnus.com In-reply-to: Your message of Sat, 14 Aug 1999 22:10:58 PDT. <37B64BE1.76D3C98D@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Aug 1999 00:13:00 -0600 Message-ID: <20740.934783980@upchuck.cygnus.com> From: Jeffrey A Law In message <37B64BE1.76D3C98D@earthlink.net>you write: > Thanks for the information. I got version 2.9.5.0.6 of binutils, > and was able to build gcc2.95 for powerpc-unknown-linux-gnulibc1 > without a hitch. > > If someone reading this could update the web page > for system specific instructions for installing gcc2.95 > on powerpc-linux to mention binutils > version 2.9.4.0.8 instead of 2.9.1.0.23, I would appreciate it. I'm not sure when it happened, but the web page already mentions binutils-2.9.1.0.23. http://egcs.cygnus.com/install/specific.html jeff From gcc-return-9123-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 06:20:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27442 invoked by alias); 16 Aug 1999 06:20:39 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27425 invoked from network); 16 Aug 1999 06:20:27 -0000 Received: from 209-249-66-150.snj0.flashcom.net (HELO ocean.lucon.org) (postfix@209.249.66.150) by egcs.cygnus.com with SMTP; 16 Aug 1999 06:20:27 -0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 12E988EEE; Sun, 15 Aug 1999 23:19:49 -0700 (PDT) Subject: Re: gcc2.95 installed To: law@cygnus.com Date: Sun, 15 Aug 1999 23:19:49 -0700 (PDT) Cc: weaver@ieee.org, Franz.Sirl-kernel@lauterbach.com (Franz Sirl), gcc@gcc.gnu.org In-Reply-To: <20740.934783980@upchuck.cygnus.com> from "Jeffrey A Law" at Aug 16, 1999 12:13:00 AM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990816061949.12E988EEE@ocean.lucon.org> From: hjl@lucon.org (H.J. Lu) > > In message <37B64BE1.76D3C98D@earthlink.net>you write: > > Thanks for the information. I got version 2.9.5.0.6 of binutils, > > and was able to build gcc2.95 for powerpc-unknown-linux-gnulibc1 > > without a hitch. > > > > If someone reading this could update the web page > > for system specific instructions for installing gcc2.95 > > on powerpc-linux to mention binutils > > version 2.9.4.0.8 instead of 2.9.1.0.23, I would appreciate it. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I'm not sure when it happened, but the web page already mentions > binutils-2.9.1.0.23. > So? He said 2.9.1.0.23 was no good on Linux/PPC and 2.9.4.0.8 or above should be used instead. H.J. From gcc-return-9124-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 06:25:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28509 invoked by alias); 16 Aug 1999 06:24:52 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28494 invoked from network); 16 Aug 1999 06:24:50 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 16 Aug 1999 06:24:50 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id AAA20832; Mon, 16 Aug 1999 00:21:35 -0600 X-Mailer: exmh version 2.0.2 To: hjl@lucon.org (H.J. Lu) cc: weaver@ieee.org, Franz.Sirl-kernel@lauterbach.com (Franz Sirl), gcc@gcc.gnu.org Subject: Re: gcc2.95 installed Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 15 Aug 1999 23:19:49 PDT. <19990816061949.12E988EEE@ocean.lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Aug 1999 00:21:35 -0600 Message-ID: <20829.934784495@upchuck.cygnus.com> From: Jeffrey A Law In message <19990816061949.12E988EEE@ocean.lucon.org>you write: > > > > In message <37B64BE1.76D3C98D@earthlink.net>you write: > > > Thanks for the information. I got version 2.9.5.0.6 of binutils, > > > and was able to build gcc2.95 for powerpc-unknown-linux-gnulibc1 > > > without a hitch. > > > > > > If someone reading this could update the web page > > > for system specific instructions for installing gcc2.95 > > > on powerpc-linux to mention binutils > > > version 2.9.4.0.8 instead of 2.9.1.0.23, I would appreciate it. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > I'm not sure when it happened, but the web page already mentions > > binutils-2.9.1.0.23. > > > > So? He said 2.9.1.0.23 was no good on Linux/PPC and 2.9.4.0.8 or above > should be used instead. Sorry. I mis-read it. THanks. I'll update the docs. jeff From gcc-return-9125-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 07:03:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1560 invoked by alias); 16 Aug 1999 07:02:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1543 invoked from network); 16 Aug 1999 07:02:51 -0000 Received: from sun475.cs.tsinghua.edu.cn (166.111.68.104) by egcs.cygnus.com with SMTP; 16 Aug 1999 07:02:51 -0000 Received: from honey (sed3) by sun475.cs.tsinghua.edu.cn (5.0/SMI-SVR4) id AA01127; Mon, 16 Aug 1999 15:00:39 --800 Message-Id: <001001bee7b5$4c2da830$0601a8c0@honey.cs.tsinghua.edu.cn> From: "Wang Yong" To: "gcc maillist" Subject: about the 'for' statement Date: Mon, 16 Aug 1999 15:02:23 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Hi, all in gcc, how 'for' statement is translated? for example: for (i=1;i++;i<10){ //some statement here } If this for statement will be translated to something like this : i=1; l1: if (i<10){ //some statements here i++; goto l1; } or i=1; l1: i++; if (i<10){ //some statements here goto l1; } From gcc-return-9126-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 07:37:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4951 invoked by alias); 16 Aug 1999 07:37:14 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4934 invoked from network); 16 Aug 1999 07:37:12 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 16 Aug 1999 07:37:12 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990816073710.DDLX9770.mail.rdc1.md.home.com@home.com> for ; Mon, 16 Aug 1999 00:37:10 -0700 Message-ID: <37B7C021.4068385F@home.com> Date: Mon, 16 Aug 1999 03:39:13 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Recursion Optimization Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Does gcc optimize in any way to minimize the cost of recursive functions calls. In particular: ONE: Does gcc optimize tail recursive functions into simple loops? TWO: In a function call like this: int sum(int i, int stop) { if (i == stop) return i; else return sum(i+1, stop) + i; } Will gcc recognize that the value of the second parameter never changes so that it can avoid allocating multiple copies of it on the stack. -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-9127-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 08:00:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8626 invoked by alias); 16 Aug 1999 08:00:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8611 invoked from network); 16 Aug 1999 08:00:35 -0000 Received: from border.cph.dk (HELO cph.dk) (@194.182.255.2) by egcs.cygnus.com with SMTP; 16 Aug 1999 08:00:35 -0000 Received: from jagger.cph.dk ([10.100.234.25]) by border.cph.dk with SMTP id <60048>; Mon, 16 Aug 1999 07:56:44 +0000 Received: from 10.100.234.25 by jagger.cph.dk (InterScan E-Mail VirusWall NT); Mon, 16 Aug 1999 10:00:20 +0200 (W. Europe Daylight Time) Received: by jagger.cph.dk with Internet Mail Service (5.5.2448.0) id ; Mon, 16 Aug 1999 10:00:20 +0200 Message-ID: <00FEB9A33E3CD211818D0000C110585F23374D@bowie.cph.dk> From: Jan Borris To: "'gcc@gcc.gnu.org'" Subject: gcc 2.95/egcs-1.1.2 Date: Mon, 16 Aug 1999 08:00:15 +0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hello, We have just decided to use egcs on our AIX platform, and have successfully installed egcs 1.1.2 on AIX 4.2 and 4.3, and compiled a lot of our code. As I understand from reading http://egcs.cygnus.com/gcc-2.95/caveats.html the libraries compiled with egcs 1.1.2 will have to be recompiled in order to link with code generated by gcc 2.95, is that correct ?? Best regards Jan Borris From gcc-return-9128-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 08:17:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11045 invoked by alias); 16 Aug 1999 08:17:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11017 invoked from network); 16 Aug 1999 08:17:19 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 16 Aug 1999 08:17:19 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id B926732D8F; Mon, 16 Aug 1999 10:15:40 +0200 (MEST) Received: from Wotan.suse.de (Wotan.suse.de [10.10.0.1]) by Galois.suse.de (Postfix) with ESMTP id 6DEA167B1; Mon, 16 Aug 1999 10:15:36 +0200 (MEST) Received: from hawking.suse.de (Hawking.suse.de [10.10.0.89]) by Wotan.suse.de (Postfix) with ESMTP id 5D3337F8B; Mon, 16 Aug 1999 10:16:30 +0200 (MEST) Received: (from schwab@localhost) by hawking.suse.de (8.9.3/8.9.3) id KAA11531; Mon, 16 Aug 1999 10:16:37 +0200 To: Jason Merrill Cc: "Kaveh R. Ghazi" , rth@cygnus.com, egcs-patches@egcs.cygnus.com, egcs@egcs.cygnus.com Subject: Re: What should -Wmissing-noreturn do with "int main(){exit(0);}" ? References: <199908142314.TAA17260@caip.rutgers.edu> X-Yow: I'm meditating on the FORMALDEHYDE and the ASBESTOS leaking into my PERSONAL SPACE!! From: Andreas Schwab Date: 16 Aug 1999 10:16:37 +0200 In-Reply-To: Jason Merrill's message of "15 Aug 1999 12:26:41 -0700" Message-ID: Lines: 20 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Jason Merrill writes: |> >>>>> Kaveh R Ghazi writes: |> |> > Well think about what one would need to do to silence the |> > warning. Is it useful to declare `main' as noreturn? |> |> If it doesn't return, it doesn't return. Calling exit bypasses the return |> from main. It doesn't make much sense to me, stylistically; I'd suggest |> changing the exit call to a return statement Returning from main and exit are two different things in some cases (think about setvbuf with the buffer allocated on the stack). Andreas. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg From gcc-return-9129-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 09:03:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14759 invoked by alias); 16 Aug 1999 09:03:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14734 invoked from network); 16 Aug 1999 09:03:08 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 16 Aug 1999 09:03:08 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id B73C032D8E; Mon, 16 Aug 1999 11:01:27 +0200 (MEST) Received: from Wotan.suse.de (Wotan.suse.de [10.10.0.1]) by Galois.suse.de (Postfix) with ESMTP id 1A0D867B1; Mon, 16 Aug 1999 11:01:27 +0200 (MEST) Received: from hawking.suse.de (Hawking.suse.de [10.10.0.89]) by Wotan.suse.de (Postfix) with ESMTP id ED3447F8B; Mon, 16 Aug 1999 11:02:15 +0200 (MEST) Received: (from schwab@localhost) by hawking.suse.de (8.9.3/8.9.3) id LAA26002; Mon, 16 Aug 1999 11:02:22 +0200 To: Kevin Atkinson Cc: gcc@gcc.gnu.org Subject: Re: Recursion Optimization References: <37B7C021.4068385F@home.com> X-Yow: Why is everything made of Lycra Spandex? From: Andreas Schwab Date: 16 Aug 1999 11:02:22 +0200 In-Reply-To: Kevin Atkinson's message of "Mon, 16 Aug 1999 03:39:13 -0400" Message-ID: Lines: 29 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Kevin Atkinson writes: |> Does gcc optimize in any way to minimize the cost of recursive functions |> calls. In particular: |> |> ONE: |> |> Does gcc optimize tail recursive functions into simple loops? |> |> TWO: |> |> In a function call like this: |> |> int sum(int i, int stop) { |> if (i == stop) return i; |> else return sum(i+1, stop) + i; |> } This is not a tail recursive function. |> Will gcc recognize that the value of the second parameter never changes |> so that it can avoid allocating multiple copies of it on the stack. This cannot be avoided. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg From gcc-return-9130-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 09:19:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17356 invoked by alias); 16 Aug 1999 09:19:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17341 invoked from network); 16 Aug 1999 09:19:41 -0000 Received: from guardian.hermes.si (193.77.5.150) by egcs.cygnus.com with SMTP; 16 Aug 1999 09:19:41 -0000 Received: from hermes.si (primus.hermes.si [193.77.5.98]) by guardian.hermes.si (8.9.3/8.9.3) with ESMTP id LAA14620; Mon, 16 Aug 1999 11:19:02 +0200 (METDST) Received: from lux.hermes.si (lux.hermes.si [10.17.4.137]) by hermes.si (8.9.3/8.9.3) with SMTP id LAA02724; Mon, 16 Aug 1999 11:18:51 +0200 (METDST) Received: from hermes.si by lux.hermes.si (SMI-8.6/SMI-SVR4) id KAA27321; Mon, 16 Aug 1999 10:15:32 +0200 Message-ID: <37B7C8AB.E7AF1FD7@hermes.si> Date: Mon, 16 Aug 1999 10:15:39 +0200 From: Branko Cibej Organization: HERMES SoftLab X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: sl,en-GB,en MIME-Version: 1.0 To: Wang Yong CC: gcc maillist Subject: Re: about the 'for' statement References: <001001bee7b5$4c2da830$0601a8c0@honey.cs.tsinghua.edu.cn> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Wang Yong wrote: > Hi, all > in gcc, This has nothing to do with gcc. This is a question about the C (or C++) language. > how 'for' statement is translated? > > for example: > > for (i=1;i++;i<10){ > //some statement here > } > > If this for statement will be translated to something like this : > > i=1; > l1: > if (i<10){ > //some statements here > i++; > goto l1; > } > > or > > i=1; > l1: > i++; > if (i<10){ > //some statements here > goto l1; > } Neither, of course :-) From your example, you'll get this: i=1; l1: if (i++) { /*some statements here*/ i<10; goto l1; } On the other hand, if you put the condition in the right place: for (i=1; i<10; i++) { /*some statements here*/ } you'll get your first expansion. Brane -- Branko Èibej HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia voice: (+386 61) 186 53 49 fax: (+386 61) 186 52 70 From gcc-return-9131-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 12:14:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17147 invoked by alias); 16 Aug 1999 12:14:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17002 invoked from network); 16 Aug 1999 12:14:38 -0000 Received: from muguet.saclay.cea.fr (132.166.192.6) by egcs.cygnus.com with SMTP; 16 Aug 1999 12:14:38 -0000 Received: from pendragon-int.shfj.cea.fr (pendragon.shfj.cea.fr [132.166.81.1]) by muguet.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.1.D20) with SMTP id OAA19676 for ; Mon, 16 Aug 1999 14:11:25 +0200 (MET DST) Received: by pendragon-int.shfj.cea.fr; id OAA11387; Mon, 16 Aug 1999 14:05:19 +0200 Received: from uriens.shfj.cea.fr(193.48.23.6) by pendragon-int.shfj.cea.fr via smap (3.2) id xma011384; Mon, 16 Aug 99 14:05:10 +0200 Received: from orcanie.shfj.cea.fr by shfj.cea.fr (8.6.10/PROTO-CEANET-3.0) with ESMTP id OAA03594 for ; Mon, 16 Aug 1999 14:10:33 +0200 Received: from shfj.cea.fr (localhost [127.0.0.1]) by orcanie.shfj.cea.fr (8.9.1b+Sun/8.9.1) with ESMTP id OAA05935 for ; Mon, 16 Aug 1999 14:11:26 +0200 (MET DST) Message-ID: <37B7FFED.5B4270F4@shfj.cea.fr> Date: Mon, 16 Aug 1999 14:11:25 +0200 From: Dimitri Papadopoulos Organization: SHFJ X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: French/France, fr-FR, Greek, en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: ANSI C++ forbids declaration `...' with no type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I am trying to compile X11 headers with gcc-2.95 on Solaris. I read the FAQ and added -fpermissive to my options. This changes errors into warnings. Now, how to remove these warnings? -w works but is obviously not a good solution... -Wno-return-type does not work. Any ideas? Thanks in advance, -- Dimitri Papadopoulos From gcc-return-9132-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 13:31:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9619 invoked by alias); 16 Aug 1999 13:31:36 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9560 invoked from network); 16 Aug 1999 13:31:32 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 16 Aug 1999 13:31:32 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id GAA04621; Mon, 16 Aug 1999 06:30:03 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id GAA04676; Mon, 16 Aug 1999 06:30:03 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id GAA05556; Mon, 16 Aug 1999 06:30:02 -0700 Message-Id: <199908161330.GAA05556@atrus.synopsys.com> Subject: Re: surprising optimization results To: burchard@pobox.com (Paul Burchard) Date: Mon, 16 Aug 99 6:30:00 PDT Cc: gcc@gcc.gnu.org In-Reply-To: <37B67040.CAA6547C@pobox.com>; from "Paul Burchard" at Aug 15, 99 12:46 am X-Mailer: ELM [version 2.3 PL11] > Inlines which call and return by value (even struct value) are showing > up consistently faster in my tests than the equivalent inlines which > call and return using non-const reference args (gcc configuration > below). Assuming this is a real effect, it is surprising to me -- but > perhaps not to those more familiar with gcc's optimization strategies > (maybe by-value makes alias analysis easier?). Any insight into tuning > my code for gcc-optimizability is appreciated... Inline functions in gcc suffer because gcc makes a decision too early about what needs to go into memory. In this case, I believe it is because the arguments have their addresses taken, they are forced to memory. After inlining, arguably there is no longer any object that has its address taken.. But often the generated code still has dead stores in it (structs or classes written to memory and never read back). From gcc-return-9133-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 13:32:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9887 invoked by alias); 16 Aug 1999 13:31:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9837 invoked from network); 16 Aug 1999 13:31:55 -0000 Received: from d12lmsgate.de.ibm.com (HELO d12lmsgate) (195.212.91.199) by egcs.cygnus.com with SMTP; 16 Aug 1999 13:31:55 -0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate (1.0.0) with ESMTP id PAA56404 for ; Mon, 16 Aug 1999 15:28:31 +0200 From: veksler@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.7m1/NCO v2.04) with SMTP id PAA182918 for ; Mon, 16 Aug 1999 15:31:21 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id C12567CF.004A4614 ; Mon, 16 Aug 1999 15:31:16 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: egcs@egcs.cygnus.com Message-ID: Date: Mon, 16 Aug 1999 16:30:59 +0300 Subject: Deadly optimization bug (all gcc versions!) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline The bug shows itself on gcc-2.7.0 gcc-2.7.2.1, egcs-1.0.1, egcs-1.1.2, gcc-2.95. On AIX-4.1, Linux-x86 (RH4.2 and RH6.0). Just try to compile the following code once with -O and once without. This may be the reason behind some of the problems with Linux-2.2.xx (I mail this here, after it was suggested to me that gnu.gcc.help is the wrong place.) The code: ---------- bug.c -------- #include /* If one=1, then the output should be: bit&1 */ unsigned test(unsigned one , unsigned bit) { unsigned val= bit & 1; unsigned zero= one >> 1; val++; return zero + ( val>> 1 ); } int main() { printf("ret=%d\n", test(1,0)); /* should print 0 */ printf("ret=%d\n", test(1,1)); /* should print 1 */ printf("ret=%d\n", test(1,65535)); /* should print 1 */ return 0; } From gcc-return-9134-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 16:05:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4460 invoked by alias); 16 Aug 1999 16:04:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4437 invoked from network); 16 Aug 1999 16:04:51 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 16 Aug 1999 16:04:51 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id SAA14337 for ; Mon, 16 Aug 1999 18:04:39 +0200 (MET DST) Date: Mon, 16 Aug 1999 18:04:37 +0200 (MET DST) From: Gerald Pfeifer To: gcc@gcc.gnu.org Subject: egcs_update vs gcc_update Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In the process of the merger, I would like to rename contrib/egcs_update to contrib/gcc_update and update the web pages accordingly (mentioning that for 2.95.x the script will keep its old name). Are there any problems with this? Shall I proceed? Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9135-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 16:16:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6534 invoked by alias); 16 Aug 1999 16:16:16 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6508 invoked from network); 16 Aug 1999 16:15:51 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 16 Aug 1999 16:15:51 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id KAA21905; Mon, 16 Aug 1999 10:12:12 -0600 X-Mailer: exmh version 2.0.2 To: Gerald Pfeifer cc: gcc@gcc.gnu.org Subject: Re: egcs_update vs gcc_update Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 16 Aug 1999 18:04:37 +0200. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Aug 1999 10:12:12 -0600 Message-ID: <21902.934819932@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > In the process of the merger, I would like to rename contrib/egcs_update > to contrib/gcc_update and update the web pages accordingly (mentioning > that for 2.95.x the script will keep its old name). > > Are there any problems with this? Shall I proceed? Go right ahead. jeff From gcc-return-9136-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 16:27:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9131 invoked by alias); 16 Aug 1999 16:27:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9062 invoked from network); 16 Aug 1999 16:27:30 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 16 Aug 1999 16:27:30 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id A1E2232DB1; Mon, 16 Aug 1999 18:26:59 +0200 (MEST) Received: from Wotan.suse.de (Wotan.suse.de [10.10.0.1]) by Galois.suse.de (Postfix) with ESMTP id 0890E67A8; Mon, 16 Aug 1999 18:26:58 +0200 (MEST) Received: from hawking.suse.de (Hawking.suse.de [10.10.0.89]) by Wotan.suse.de (Postfix) with ESMTP id 6ED747F8B; Mon, 16 Aug 1999 18:26:55 +0200 (MEST) Received: (from schwab@localhost) by hawking.suse.de (8.9.3/8.9.3) id SAA06238; Mon, 16 Aug 1999 18:26:50 +0200 To: Kevin Atkinson Cc: gcc@gcc.gnu.org Subject: Re: Recursion Optimization References: X-Yow: FOOLED you! Absorb EGO SHATTERING impulse rays, polyester poltroon!! From: Andreas Schwab Date: 16 Aug 1999 18:26:50 +0200 In-Reply-To: Kevin Atkinson's message of "Mon, 16 Aug 1999 12:20:04 -0400 (EDT)" Message-ID: Lines: 56 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Kevin Atkinson writes: |> On 16 Aug 1999, Andreas Schwab wrote: |> |> > Kevin Atkinson writes: |> > |> > |> Does gcc optimize in any way to minimize the cost of recursive functions |> > |> calls. In particular: |> > |> |> > |> ONE: |> > |> |> > |> Does gcc optimize tail recursive functions into simple loops? |> |> You never answered this question. Because I don't know the answer. I do not know everything. |> > |> TWO: |> > |> |> > |> In a function call like this: |> > |> |> > |> int sum(int i, int stop) { |> > |> } |> > |> > This is not a tail recursive function. |> |> I know. |> |> > |> Will gcc recognize that the value of the second parameter never changes |> > |> so that it can avoid allocating multiple copies of it on the stack. |> > |> > This cannot be avoided. |> |> What do you mean, cannot. How can you provide a contiguous argument list on the stack for the recursive call without the copy? |> Gcc can handel nested functions, so with a smart enough optimization |> technoligy it out to be able to rewrite it as |> |> int sum (int i, int stop) { |> int sumh(int i) { |> if (i == stop) return i; |> else return sum(i+1, stop) + i; |> } |> return sumh(i); |> } In which way is this different from the previous version? You still have the same call to sum which requires a contiguous argument list on the stack. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg From gcc-return-9137-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 16:30:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10261 invoked by alias); 16 Aug 1999 16:30:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10222 invoked from network); 16 Aug 1999 16:30:42 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 16 Aug 1999 16:30:42 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990816163040.GFND9770.mail.rdc1.md.home.com@home.com>; Mon, 16 Aug 1999 09:30:40 -0700 Message-ID: <37B83D2E.69CFDDFF@home.com> Date: Mon, 16 Aug 1999 12:32:46 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Schwab CC: gcc@gcc.gnu.org Subject: Re: Recursion Optimization Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 16 Aug 1999, Andreas Schwab wrote: > Kevin Atkinson writes: > > |> Does gcc optimize in any way to minimize the cost of recursive functions > |> calls. In particular: > |> > |> ONE: > |> > |> Does gcc optimize tail recursive functions into simple loops? You never answered this question. > |> TWO: > |> > |> In a function call like this: > |> > |> int sum(int i, int stop) { > |> } > > This is not a tail recursive function. I know. > |> Will gcc recognize that the value of the second parameter never changes > |> so that it can avoid allocating multiple copies of it on the stack. > > This cannot be avoided. What do you mean, cannot. Gcc can handel nested functions, so with a smart enough optimization technoligy it out to be able to rewrite it as int sum (int i, int stop) { int sumh(int i) { if (i == stop) return i; else return sum(i+1, stop) + i; } return sumh(i); } From gcc-return-9138-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 16:41:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13392 invoked by alias); 16 Aug 1999 16:41:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13375 invoked from network); 16 Aug 1999 16:41:40 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by egcs.cygnus.com with SMTP; 16 Aug 1999 16:41:40 -0000 Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id MAA06252 for ; Mon, 16 Aug 1999 12:41:38 -0400 Received: from marc.watson.ibm.com (marc.watson.ibm.com [9.2.176.11]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id MAA21590 for ; Mon, 16 Aug 1999 12:41:38 -0400 Received: from localhost by marc.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA40226; Mon, 16 Aug 1999 12:41:32 -0400 Message-Id: <9908161641.AA40226@marc.watson.ibm.com> To: veksler@il.ibm.com Cc: egcs@egcs.cygnus.com Subject: Re: Deadly optimization bug (all gcc versions!) In-Reply-To: Message from veksler@il.ibm.com of "Mon, 16 Aug 1999 16:30:59 +0300." Date: Mon, 16 Aug 1999 12:41:31 -0400 From: David Edelsohn >>>>> veksler writes: veksler> The bug shows itself on gcc-2.7.0 gcc-2.7.2.1, egcs-1.0.1, egcs-1.1.2, veksler> gcc-2.95. veksler> On AIX-4.1, Linux-x86 (RH4.2 and RH6.0). This means that you have seen the bug in both PowerPC and IA-32 code generation? I definitely see it in PowerPC. A whole group of instructions disappear between flow and combine. Also, -O3 with inlining seems to produce correct results. Maybe combine is trying some alternate instructions, failing, and then not properly restoring the instructions? David From gcc-return-9139-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 16:54:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15199 invoked by alias); 16 Aug 1999 16:54:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15169 invoked from network); 16 Aug 1999 16:54:15 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 16 Aug 1999 16:54:15 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id SAA15302; Mon, 16 Aug 1999 18:54:05 +0200 (MET DST) Date: Mon, 16 Aug 1999 18:54:03 +0200 (MET DST) From: Gerald Pfeifer To: Jeffrey A Law cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: egcs_update vs gcc_update In-Reply-To: <21902.934819932@upchuck.cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 16 Aug 1999, Jeffrey A Law wrote: > Go right ahead. Quick response, wow! :-) Here is what I put in: 1999-08-16 Gerald Pfeifer * gcc_update: New file. * egcs_update: Renamed to gcc_update. And for the web pages: Rename egcs_update to gcc_update (after GCC 2.95.x). Fix some egcs vs GCC issues. Index: faq.html =================================================================== RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/faq.html,v retrieving revision 1.143 diff -c -3 -p -r1.143 faq.html *** faq.html 1999/08/16 06:02:56 1.143 --- faq.html 1999/08/16 16:51:26 *************** bison, and xgettext.

*** 855,869 **** correct. This causes problems for generated files as "make" may think those generated files are out of date and try to regenerate them.

!

An easy way to work around this problem is to use the egcs_update ! script in the contrib subdirectory of egcs, which handles this ! transparently without requiring installation of any additional tools.

When building from diffs or CVS or if you modified some sources, you may also need to obtain development versions of some GNU tools, as the production versions do not necessarily handle all features needed ! to rebuild egcs.

Autoconf is available from --- 855,871 ---- correct. This causes problems for generated files as "make" may think those generated files are out of date and try to regenerate them.

!

An easy way to work around this problem is to use the gcc_update ! script in the contrib subdirectory of GCC, which handles this ! transparently without requiring installation of any additional tools. ! (Note: Up to and including GCC 2.95 this script was called egcs_update ! .)

When building from diffs or CVS or if you modified some sources, you may also need to obtain development versions of some GNU tools, as the production versions do not necessarily handle all features needed ! to rebuild GCC.

Autoconf is available from *************** is declared pure-virtual [class.dtor]/7. *** 1033,1039 ****

Return to the GCC home page

!

Last modified: August 15, 1999

--- 1035,1041 ----

Return to the GCC home page

!

Last modified: August 16, 1999

From gcc-return-9140-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 17:23:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24085 invoked by alias); 16 Aug 1999 17:23:52 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24066 invoked from network); 16 Aug 1999 17:23:49 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 16 Aug 1999 17:23:49 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990816172347.GQTT9770.mail.rdc1.md.home.com@home.com>; Mon, 16 Aug 1999 10:23:47 -0700 Message-ID: <37B849A2.5E32C3DB@home.com> Date: Mon, 16 Aug 1999 13:25:54 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Schwab CC: gcc@gcc.gnu.org Subject: Re: Recursion Optimization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andreas Schwab wrote: > |> > |> TWO: > |> > |> > |> > |> In a function call like this: > |> > |> > |> > |> int sum(int i, int stop) { > |> > |> } > |> > |> > |> Will gcc recognize that the value of the second parameter never changes > |> > |> so that it can avoid allocating multiple copies of it on the stack. > |> > > |> > This cannot be avoided. > ... > |> Gcc can handel nested functions, so with a smart enough optimization > |> technoligy it out to be able to rewrite it as > |> > |> int sum (int i, int stop) { > |> int sumh(int i) { > |> if (i == stop) return i; > |> else return sum(i+1, stop) + i; > |> } > |> return sumh(i); > |> } > > In which way is this different from the previous version? You still have > the same call to sum which requires a contiguous argument list on the stack. Stop only gets allocated on the stack once as it is not a parameter of sumh. Each call to sumh will only allocated a new copy of i, not stop. Now back to my orignal question: Will gcc recognize that the value of the __second__ parameter (IE stop) never change so that it can avoid allocating multiple copies of it on the stack. -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-9141-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 17:27:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25496 invoked by alias); 16 Aug 1999 17:27:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25419 invoked from network); 16 Aug 1999 17:27:13 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 16 Aug 1999 17:27:13 -0000 Received: (qmail 17742 invoked by alias); 16 Aug 1999 17:27:11 -0000 Received: (qmail 17737 invoked from network); 16 Aug 1999 17:27:11 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 16 Aug 1999 17:27:11 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id SAA02126; Mon, 16 Aug 1999 18:26:43 +0100 From: Joern Rennecke Message-Id: <199908161726.SAA02126@phal.cygnus.co.uk> Subject: Re: GCC 2.95 x Kernel 2.2.11-ac2 Opt. 'Problems' with RAID ??? In-Reply-To: <37B57CF2.58701843@opensystem.org.br> from Leonardo Marques de Souza at "Aug 14, 1999 2:28: 2 pm" To: leo@opensystem.org.br Date: Mon, 16 Aug 1999 18:26:43 +0100 (BST) Cc: gcc@gcc.gnu.org X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > After modify to -O9 -march=k6 i got -O3 and higher enables -finline-functions. This is not always a win. From gcc-return-9142-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 17:29:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26552 invoked by alias); 16 Aug 1999 17:29:37 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26529 invoked from network); 16 Aug 1999 17:29:36 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 16 Aug 1999 17:29:36 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id OAA29032; Mon, 16 Aug 1999 14:25:03 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id NAA18859; Mon, 16 Aug 1999 13:25:57 -0300 (EST) To: Dimitri Papadopoulos Cc: gcc@gcc.gnu.org Subject: Re: ANSI C++ forbids declaration `...' with no type References: <37B7FFED.5B4270F4@shfj.cea.fr> From: Alexandre Oliva Date: 16 Aug 1999 13:29:52 -0300 In-Reply-To: Dimitri Papadopoulos's message of "Mon, 16 Aug 1999 14:11:25 +0200" Message-ID: Lines: 15 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 16, 1999, Dimitri Papadopoulos wrote: > I am trying to compile X11 headers with gcc-2.95 on Solaris. I read the > FAQ and added -fpermissive to my options. > This changes errors into warnings. Now, how to remove these warnings? Use `-isystem /usr/openwin/include' instead of `-fpermissive -I/usr/openwin/include' -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9143-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 17:42:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29755 invoked by alias); 16 Aug 1999 17:42:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29739 invoked from network); 16 Aug 1999 17:42:40 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 16 Aug 1999 17:42:40 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA01374; Mon, 16 Aug 1999 10:42:39 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id KAA16388; Mon, 16 Aug 1999 10:42:39 -0700 (PDT) Date: Mon, 16 Aug 1999 10:42:39 -0700 (PDT) Message-Id: <199908161742.KAA16388@kankakee.wrs.com> To: burchard@pobox.com, gcc@gcc.gnu.org Subject: Re: surprising optimization results > Date: Sun, 15 Aug 1999 00:46:08 -0700 > From: Paul Burchard > Inlines which call and return by value (even struct value) are > showing up consistently faster in my tests than the equivalent > inlines which call and return using non-const reference args (gcc > configuration below). Assuming this is a real effect, it is > surprising to me -- but perhaps not to those more familiar with > gcc's optimization strategies (maybe by-value makes alias analysis > easier?). :-) Predictable. Glad you noticed the cool codegen strategies in the compiler. I think the one you are observing are the results of ADDRESSOF. References kill a bit of optimizability, though the limits of what the compiler can and can't do are pushed farther out every now and then. From gcc-return-9144-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 17:48:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31911 invoked by alias); 16 Aug 1999 17:48:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31890 invoked from network); 16 Aug 1999 17:48:38 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 16 Aug 1999 17:48:38 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA02173; Mon, 16 Aug 1999 10:48:26 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id KAA16411; Mon, 16 Aug 1999 10:48:26 -0700 (PDT) Date: Mon, 16 Aug 1999 10:48:26 -0700 (PDT) Message-Id: <199908161748.KAA16411@kankakee.wrs.com> To: gcc@egcs.cygnus.com, hackacio@sti.com.br Subject: Re: Linux Programming > From: "=?iso-8859-1?Q?ac=E1cio_silvestre?=" > Date: Sat, 15 Aug 1998 15:06:33 -0300 > Please, I am early in Linux programming and I would like to now how > I can set the cursor on text mode. I tried to find a function (in > libraries) like gotoxy, but I didn't. I tried to develope my own > function using inline assembly but I don't now how. No, we can't help you. This forum discusses things like the optimal way to reorder insns on a mips 5400 to avoid undocumented register interlock problems on the chip. Your question isn't that type of question. No, we can't tell you where to go either... Try a group with the word programming and linux. Also, you might want to try a book store. From gcc-return-9145-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 17:54:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1391 invoked by alias); 16 Aug 1999 17:54:12 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1365 invoked from network); 16 Aug 1999 17:54:09 -0000 Received: from out4.ibm.net (165.87.194.239) by egcs.cygnus.com with SMTP; 16 Aug 1999 17:54:09 -0000 Received: from KelleyWS (slip-32-101-184-194.mi.us.ibm.net [32.101.184.194]) by out4.ibm.net (8.8.5/8.6.9) with SMTP id RAA78804 for ; Mon, 16 Aug 1999 17:54:06 GMT From: "R. Kelley Cook" Message-ID: To: "egcs@egcs.cygnus.com" Date: Mon, 16 Aug 1999 13:53:02 -0400 (EDT) Reply-To: "R. Kelley Cook" X-Newsreader: PMINews 2.00.1201 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: about the 'for' statement On 16 Aug 1999 09:03:09 +0200, Wang Yong wrote: >Hi, all > in gcc, how 'for' statement is translated? > > for example: > > for (i=1;i++;i<10){ > //some statement here > } > Strange question, you already wrote enough to check the answer yourself. All you had to do was change your code to be ... for (i=1;i++;i<10){ printf("%d",i); //some statement here } and you would have realized the answer. > If this for statement will be translated to something like this : > > i=1; >l1: > if (i<10){ > //some statements here > i++; > goto l1; > } > yes >or > > i=1; >l1: > i++; > if (i<10){ > //some statements here > goto l1; > } no From gcc-return-9146-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 18:08:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5101 invoked by alias); 16 Aug 1999 18:08:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5064 invoked from network); 16 Aug 1999 18:08:06 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 16 Aug 1999 18:08:06 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id LAA25487; Mon, 16 Aug 1999 11:00:51 -0700 Message-Id: <199908161800.LAA25487@zack.bitmover.com> To: Andreas Schwab cc: Kevin Atkinson , gcc@gcc.gnu.org Subject: Re: Recursion Optimization In-Reply-To: Message from Andreas Schwab of "16 Aug 1999 18:26:50 +0200." Date: Mon, 16 Aug 1999 11:00:51 -0700 From: Zack Weinberg Andreas Schwab wrote: > Kevin Atkinson writes: > > |> Gcc can handel nested functions, so with a smart enough optimization > |> technoligy it out to be able to rewrite it as > |> > |> int sum (int i, int stop) { > |> int sumh(int i) { > |> if (i == stop) return i; > |> else return sum(i+1, stop) + i; > |> } > |> return sumh(i); > |> } > > In which way is this different from the previous version? You still have > the same call to sum which requires a contiguous argument list on the stack. He meant to write this: int sum(int i, int stop) { int sumh(int i) { if(i == stop) return i; else return sumh(i+1) + i; } return sumh(i); } 'stop' will be accessed via the static chain register, eliminating the need to push it on the stack. Unfortunately, you now have to push the static chain register, so you don't gain anything. What he actually wants gcc to do is something like: int sum(int i, int stop) { x: if(i == stop) goto y; else { push(i); i += 1; goto x; } y: if(stack_empty()) return i; i += pop(); goto y; } where push, pop, and stack_empty are operations on some generic stack. By doing this, you avoid having to push "stop", the return address, the frame pointer, any call-saved registers, and so on. It can be a *huge* win in terms of stack usage. You can use the function-call stack as long as you have a frame pointer to work with - this optimization would be rather difficult on AIX/PPC where there isn't one, for example. This can also enable further optimizations. A moderately intelligent compiler would recognize that the above code corresponds to int sum(int i, int stop) { for(; i < stop; i++) push(i); while(!stack_empty()) i += pop(); return i; } and loop-optimize it to death. A genius compiler would recognize that the values pushed on the stack are predictable, and generate int sum(int i, int stop) { int tmp = 0; while(i <= stop) tmp += i++; return tmp; } ... To answer the original question: No, GCC is not capable of any of these optimizations. I'm sure we would be delighted to accept contributions that gave it the ability to do them. Even adding support for general tail recursion optimization a la Scheme would be a great step forward. There is existing support for tail recursion optimization in very limited cases. I have never got it to do anything useful for non-toy functions. zw From gcc-return-9147-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 18:33:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10345 invoked by alias); 16 Aug 1999 18:33:21 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10328 invoked from network); 16 Aug 1999 18:33:13 -0000 Received: from adsl-216-102-199-253.dsl.snfc21.pacbell.net (HELO magnus.bothner.com) (root@216.102.199.253) by egcs.cygnus.com with SMTP; 16 Aug 1999 18:33:13 -0000 Received: by bothner.com via sendmail from stdin id (Debian Smail3.2.0.102) for egcs@egcs.cygnus.com; Mon, 16 Aug 1999 11:39:12 -0700 (PDT) To: "R. Kelley Cook" Cc: "egcs@egcs.cygnus.com" Subject: Re: about the 'for' statement References: From: Per Bothner Date: 16 Aug 1999 11:39:12 -0700 In-Reply-To: "R. Kelley Cook"'s message of "Mon, 16 Aug 1999 13:53:02 -0400 (EDT)" Message-ID: Lines: 33 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta14) (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "R. Kelley Cook" writes: > > for (i=1;i++;i<10){ > > //some statement here > > } > > If this for statement will be translated to something like this : > > > > i=1; > >l1: > > if (i<10){ > > //some statements here > > i++; > > goto l1; > > } > > > > yes Wrong. Try: i=1; l1: if (i++){ //some statements here i<10; // no-op. goto l1; } I.e. the i++ and i<10 are probably switched ... -- --Per Bothner bothner@pacbell.net per@bothner.com http://home.pacbell.net/bothner/ From gcc-return-9148-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 18:48:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13705 invoked by alias); 16 Aug 1999 18:48:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13680 invoked from network); 16 Aug 1999 18:48:41 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 16 Aug 1999 18:48:41 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990816184835.HJRL9770.mail.rdc1.md.home.com@home.com>; Mon, 16 Aug 1999 11:48:35 -0700 Message-ID: <37B85D83.79E0FC67@home.com> Date: Mon, 16 Aug 1999 14:50:43 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: Zack Weinberg CC: Andreas Schwab , gcc@gcc.gnu.org Subject: Re: Recursion Optimization References: <199908161800.LAA25487@zack.bitmover.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zack Weinberg wrote: > > ... To answer the original question: No, GCC is not capable of any of these > optimizations. I'm sure we would be delighted to accept contributions > that gave it the ability to do them. Even adding support for general > tail recursion optimization a la Scheme would be a great step > forward. > > There is existing support for tail recursion optimization in very > limited cases. I have never got it to do anything useful for non-toy > functions. Has anyone tried writing a front end for a functional language like ML or even Haskell for gcc. Since recursion is the heart and soul of functional languages I am sure that these sort of optimizations will also come with it. I am not sure what type of issues are involved though as a good functional compiler has to do a lot more than mere recursion optimization--especially for languages like Haskell which are not only functional but also lazy. -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-9149-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 19:44:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21613 invoked by alias); 16 Aug 1999 19:44: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21116 invoked from network); 16 Aug 1999 19:42:58 -0000 Received: from rpppc2.hns.com (139.85.108.141) by egcs.cygnus.com with SMTP; 16 Aug 1999 19:42:58 -0000 Received: from nbecker by rpppc2.hns.com with local (Exim 3.02 #1) id 11GSe8-0000S2-00 for egcs@egcs.cygnus.com; Mon, 16 Aug 1999 15:42:16 -0400 To: egcs@egcs.cygnus.com Subject: pgcc status? Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: nbecker@fred.net Date: 16 Aug 1999 15:42:16 -0400 Message-ID: Lines: 2 Is pgcc still alive? What is the status of back porting to gcc/egcs? What about code fusion? From gcc-return-9150-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 19:46:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22232 invoked by alias); 16 Aug 1999 19:46:14 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21629 invoked from network); 16 Aug 1999 19:44:39 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 16 Aug 1999 19:44:39 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id VAA01157; Mon, 16 Aug 1999 21:43:30 +0200 Message-ID: <37B869E2.30CAA4A@moene.indiv.nluug.nl> Date: Mon, 16 Aug 1999 21:43:30 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: David Edelsohn CC: veksler@il.ibm.com, egcs@egcs.cygnus.com Subject: Re: Deadly optimization bug (all gcc versions!) References: <9908161641.AA40226@marc.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Edelsohn wrote: > >>>>> veksler writes: > veksler> The bug shows itself on gcc-2.7.0 gcc-2.7.2.1, egcs-1.0.1, egcs-1.1.2, > veksler> gcc-2.95. > veksler> On AIX-4.1, Linux-x86 (RH4.2 and RH6.0). > This means that you have seen the bug in both PowerPC and IA-32 > code generation? I definitely see it in PowerPC. A whole group of > instructions disappear between flow and combine. Also, -O3 with inlining > seems to produce correct results. Maybe combine is trying some alternate > instructions, failing, and then not properly restoring the instructions? [ General Warning: I have no idea what the C Standard mandates when shifting an unsigned number by a signed quantity (i.e. the constant 1) ] I just found that on RH Linux 5.2, GNU C version 2.95.1 19990809 (prerelease) with -O produces as output: ret=0 ret=0 ret=0 whereas the non-optimized version gives: ret=0 ret=1 ret=1 in accordance with what I got from SGI's cc 7.2.1 compiler at work. > Maybe combine is trying some alternate instructions, failing, and > then not properly restoring the instructions? Or the other way around (I see a couple of NOTE_INSN_DELETED in the .combine dump where the .flow dump still has something like: (insn 4 31 6 (set (reg/v:SI 22) (mem/f:SI (reg:SI 16 %argp) 0)) 48 {movsi+2} (nil) (expr_list:REG_EQUIV (mem/f:SI (reg:SI 16 %argp) 0) (nil))) [ Flow is run before combine, isn't it - doesn't combine need some flow graph info to decide whether certain combine's are valid ? ] -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-9151-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 19:50:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23366 invoked by alias); 16 Aug 1999 19:49:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22508 invoked from network); 16 Aug 1999 19:47:04 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 16 Aug 1999 19:47:04 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id NAA22674; Mon, 16 Aug 1999 13:41:28 -0600 X-Mailer: exmh version 2.0.2 To: Jan Borris cc: "'gcc@gcc.gnu.org'" Subject: Re: gcc 2.95/egcs-1.1.2 Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 16 Aug 1999 08:00:15 -0000. <00FEB9A33E3CD211818D0000C110585F23374D@bowie.cph.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Aug 1999 13:41:28 -0600 Message-ID: <22671.934832488@upchuck.cygnus.com> From: Jeffrey A Law In message <00FEB9A33E3CD211818D0000C110585F23374D@bowie.cph.dk>you write: > the libraries compiled with egcs 1.1.2 will have to be recompiled in order > to link with code generated by gcc 2.95, is that correct ?? If they use C++, then yes, they will need to be recompiled. jeff From gcc-return-9152-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 20:28:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30533 invoked by alias); 16 Aug 1999 20:28:06 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30437 invoked from network); 16 Aug 1999 20:27:44 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 16 Aug 1999 20:27:44 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id NAA24552; Mon, 16 Aug 1999 13:20:31 -0700 Message-Id: <199908162020.NAA24552@zack.bitmover.com> To: "Kaveh R. Ghazi" cc: gcc@gcc.gnu.org Subject: Re: bootstrap failure, current CVS, enable-checking In-Reply-To: Message from "Kaveh R. Ghazi" of "Mon, 16 Aug 1999 16:08:18 EDT." <199908162008.QAA12268@caip.rutgers.edu> Date: Mon, 16 Aug 1999 13:20:31 -0700 From: Zack Weinberg "Kaveh R. Ghazi" wrote: > > From: Zack Weinberg > > > > I'm doing regular builds with --enable-checking. > > Is there a lot of overhead when doing this? Do you know why > isn't it on by default in the trunk? Moderate overhead - it adds runtime type checking to all operations on syntax trees. The current implementation is boneheaded, but I've got some improvements under development. Dunno why it isn't on by default in the trunk. It catches all sorts of problems just in the testsuite. From my latest build: noncompile/920616-2.c:1: Internal error in `pushdecl', at c-decl.c:2481: expected 't', have 'x' (error_mark) noncompile/920923-1.c:21: Internal error in `c_expand_start_case', at c-typeck.c:6717: expected 't', have 'x' (error_mark) noncompile/921116-1.c:1: Internal error in `pushdecl', at c-decl.c:2481: expected 't', have 'x' (error_mark) noncompile/940510-1.c:1: Internal error in `layout_type', at stor-layout.c:942: expected 't', have 'x' (error_mark) noncompile/990416-1.c:9: Internal error in `do_jump', at expr.c:8920: expected 't', have 'x' (error_mark) zw From gcc-return-9153-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 20:29:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31282 invoked by alias); 16 Aug 1999 20:29:37 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31081 invoked from network); 16 Aug 1999 20:29:20 -0000 Received: from dragonfly.wolfram.com (root@140.177.10.12) by egcs.cygnus.com with SMTP; 16 Aug 1999 20:29:20 -0000 Received: from m.wolfram.com (root@m.wolfram.com [140.177.201.20]) by dragonfly.wolfram.com (8.8.8/8.8.8) with ESMTP id PAA01747 for ; Mon, 16 Aug 1999 15:29:19 -0500 (CDT) Received: from localhost (johnnyb@localhost) by m.wolfram.com (8.9.3/8.9.2) with ESMTP id PAA13967 for ; Mon, 16 Aug 1999 15:25:52 -0500 Date: Mon, 16 Aug 1999 15:25:52 -0500 (CDT) From: Jonathan Bartlett To: gcc@gcc.gnu.org Subject: Cross Compiling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm trying to build a cross-compiler from a Red Hat Linux system to a Cygwin system (this is actually the first of several cross-compilers I'm trying to build, so prebuilt packages won't help). Anyway, here is the process I'm going through mkdir build_binutils cd build_binutils ../binutils-2.9.1/configure --host=i686-pc-linux-gnu \ --target=i586-pc-cygwin32 \ --prefix=/home/johnnyb/cross make make install mkdir build_gcc cd build_gcc ../gcc-2.95/configure --host=i686-pc-linux-gnu --target=i586-pc-cygwin32 \ --prefix=/home/johnnyb/cross --without-headers With this configuration issuing make gives me this error: /home/johnnyb/build_gcc/gcc/xgcc -B/home/johnnyb/build_gcc/gcc/ -B/usr/local/i586-pc-cygwin32/bin/ -I/usr/local/i586-pc-cygwin32/include -O2 -I../../gcc-2.95/gcc/../winsup/include -DCROSS_COMPILE -DIN_GCC -g -O2 -I./include -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I../../gcc-2.95/gcc -I../../gcc-2.95/gcc/config -I../../gcc-2.95/gcc/../include -c -DL${name} \ ../../gcc-2.95/gcc/libgcc2.c -o ${name}.o; \ if [ $? -eq 0 ] ; then true; else exit 1; fi; \ i586-pc-cygwin32-ar rc tmplibgcc2.a ${name}.o; \ rm -f ${name}.o; \ done _muldi3 ../../gcc-2.95/gcc/libgcc2.c:41: stdlib.h: No such file or directory ../../gcc-2.95/gcc/libgcc2.c:42: unistd.h: No such file or directory make[1]: *** [libgcc2.a] Error 1 make[1]: Leaving directory `/home/johnnyb/build_gcc/gcc' make: *** [all-gcc] Error 2 However, if I specify that I'm going to use newlib, with --with-newlib, I get: _lshrdi3 _ashldi3 _ashrdi3 _ffsdi2 _udiv_w_sdiv _udivmoddi4 _cmpdi2 _ucmpdi2 _floatdidf _floatdisf _fixunsdfsi In file included from include/syslimits.h:7, from include/limits.h:11, from ../../gcc-2.95/gcc/libgcc2.c:1105: /home/johnnyb/build_gcc/gcc/include/limits.h:117: limits.h: No such file or directory make[1]: *** [libgcc2.a] Error 1 make[1]: Leaving directory `/home/johnnyb/build_gcc/gcc' make: *** [all-gcc] Error 2 I think this is all caused because I don't have newlib installed for that platform. However, I can't install newlib for that platform until I have GCC built. Any ideas? Am I just doing it wrong? Jonathan Bartlett From gcc-return-9154-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 20:40:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2706 invoked by alias); 16 Aug 1999 20:40:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2395 invoked from network); 16 Aug 1999 20:39:32 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 16 Aug 1999 20:39:32 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id OAA22901; Mon, 16 Aug 1999 14:35:44 -0600 X-Mailer: exmh version 2.0.2 To: Jonathan Bartlett cc: gcc@gcc.gnu.org Subject: Re: Cross Compiling Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 16 Aug 1999 15:25:52 CDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Aug 1999 14:35:44 -0600 Message-ID: <22898.934835744@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > I'm trying to build a cross-compiler from a Red Hat Linux system to a > Cygwin system (this is actually the first of several cross-compilers I'm > trying to build, so prebuilt packages won't help). Anyway, here is the > process I'm going through You have to provide header files and libraries for your target system. Please read the installation instructions. jeff From gcc-return-9155-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 20:55:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6874 invoked by alias); 16 Aug 1999 20:55:12 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6857 invoked from network); 16 Aug 1999 20:55:08 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 16 Aug 1999 20:55:08 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id WAA26977; Mon, 16 Aug 1999 22:53:54 +0200 Message-ID: <37B87A62.4292BC30@moene.indiv.nluug.nl> Date: Mon, 16 Aug 1999 22:53:54 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: David Edelsohn , veksler@il.ibm.com, egcs@egcs.cygnus.com Subject: Re: Deadly optimization bug (all gcc versions!) References: <9908161641.AA40226@marc.watson.ibm.com> <37B869E2.30CAA4A@moene.indiv.nluug.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Toon Moene wrote: > David Edelsohn wrote: > > Maybe combine is trying some alternate instructions, failing, and > > then not properly restoring the instructions? > > Or the other way around (I see a couple of NOTE_INSN_DELETED in the > .combine dump where the .flow dump still has something like: > > (insn 4 31 6 (set (reg/v:SI 22) > (mem/f:SI (reg:SI 16 %argp) 0)) 48 {movsi+2} (nil) > (expr_list:REG_EQUIV (mem/f:SI (reg:SI 16 %argp) 0) > (nil))) > > [ Flow is run before combine, isn't it - doesn't combine need some > flow graph info to decide whether certain combine's are valid ? ] Sorry, got this backwards. Reprise: Flow runs. Flow dumps resulting list of insns into .flow dump file Combine runs. Combine dumps resulting list of insns into .combine dump file. Hence: diff blah.c.flow blah.c.combine shows the insns added/removed by combine. Therefore, insns removed were removed by combine. [ Sigh - shift brain in forward gear ] -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-9156-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 21:43:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15749 invoked by alias); 16 Aug 1999 21:43:53 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15720 invoked from network); 16 Aug 1999 21:43:49 -0000 Received: from linuxpc1.lauterbach.com (qmailr@194.195.165.177) by egcs.cygnus.com with SMTP; 16 Aug 1999 21:43:49 -0000 Received: (qmail 32205 invoked from network); 16 Aug 1999 21:43:45 -0000 Received: from ns1155.munich.netsurf.de (HELO ns1102.munich.netsurf.de) (195.180.235.155) by linuxpc1 with SMTP; 16 Aug 1999 21:43:45 -0000 From: Franz Sirl To: David Edelsohn , veksler@il.ibm.com Subject: Re: Deadly optimization bug (all gcc versions!) Date: Mon, 16 Aug 1999 23:32:27 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: egcs@egcs.cygnus.com References: <9908161641.AA40226@marc.watson.ibm.com> In-Reply-To: <9908161641.AA40226@marc.watson.ibm.com> MIME-Version: 1.0 Message-Id: <99081623444200.00809@ns1102.munich.netsurf.de> Content-Transfer-Encoding: 8bit Am Mon, 16 Aug 1999 schrieb David Edelsohn: >>>>>> veksler writes: > >veksler> The bug shows itself on gcc-2.7.0 gcc-2.7.2.1, egcs-1.0.1, egcs-1.1.2, >veksler> gcc-2.95. >veksler> On AIX-4.1, Linux-x86 (RH4.2 and RH6.0). > > This means that you have seen the bug in both PowerPC and IA-32 >code generation? I definitely see it in PowerPC. A whole group of >instructions disappear between flow and combine. Also, -O3 with inlining >seems to produce correct results. Maybe combine is trying some alternate >instructions, failing, and then not properly restoring the instructions? Currently I'm lost in try_combine(). It is called by this code around line 660 in combine.c: /* Try combining an insn with two different insns whose results it uses. */ for (links = LOG_LINKS (insn); links; links = XEXP (links, 1)) for (nextlinks = XEXP (links, 1); nextlinks; nextlinks = XEXP (nextlinks, 1)) if ((next = try_combine (insn, XEXP (links, 0), XEXP (nextlinks, 0))) != 0) goto retry; After the call to try_combine the instructions are deleted. try_combine is entered with: (gdb) p debug_rtx(i3) (insn 22 20 24 (set (reg:SI 86) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1]))) 52 {*addsi3_internal1} (insn_list 14 (insn_list 20 (nil))) (expr_list:REG_DEAD (reg/v:SI 85) (expr_list:REG_DEAD (reg:SI 87) (nil)))) $134 = void (gdb) p debug_rtx(i2) (insn 20 17 22 (set (reg:SI 87) (lshiftrt:SI (reg/v:SI 84) (const_int 1 [0x1]))) 211 {lshrsi3_no_power} (insn_list 17 (nil)) (expr_list:REG_DEAD (reg/v:SI 84) (nil))) $135 = void (gdb) p debug_rtx(i1) (insn 14 11 17 (set (reg/v:SI 85) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1]))) 211 {lshrsi3_no_power} (nil) (expr_list:REG_DEAD (reg:SI 3 r3) (nil))) and this instruction list: (note 7 6 8 "" NOTE_INSN_FUNCTION_BEG) (note 8 7 10 "" NOTE_INSN_DELETED) (note 10 8 11 0 NOTE_INSN_BLOCK_BEG) (insn 11 10 14 (parallel[ (set (reg/v:SI 84) (and:SI (reg:SI 4 r4) (const_int 1 [0x1]))) (clobber (scratch:CC)) ] ) 121 {andsi3} (nil) (expr_list:REG_DEAD (reg:SI 4 r4) (expr_list:REG_UNUSED (scratch:CC) (nil)))) (insn 14 11 17 (set (reg/v:SI 85) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1]))) 211 {lshrsi3_no_power} (nil) (expr_list:REG_DEAD (reg:SI 3 r3) (nil))) (insn 17 14 20 (set (reg/v:SI 84) (plus:SI (reg/v:SI 84) (const_int 1 [0x1]))) 52 {*addsi3_internal1} (insn_list 11 (nil)) (nil)) (insn 20 17 22 (set (reg:SI 87) (lshiftrt:SI (reg/v:SI 84) (const_int 1 [0x1]))) 211 {lshrsi3_no_power} (insn_list 17 (nil)) (expr_list:REG_DEAD (reg/v:SI 84) (nil))) (insn 22 20 24 (set (reg:SI 86) (plus:SI (reg/v:SI 85) (reg:SI 87))) 52 {*addsi3_internal1} (insn_list 14 (insn_list 20 (nil))) (expr_list:REG_DEAD (reg/v:SI 85) (expr_list:REG_DEAD (reg:SI 87) (nil)))) (insn 24 22 25 (set (reg/i:SI 3 r3) (reg:SI 86)) 426 {movsi+1} (insn_list 22 (nil)) (expr_list:REG_DEAD (reg:SI 86) (nil))) (insn 25 24 29 (use (reg/i:SI 3 r3)) -1 (insn_list 24 (nil)) (expr_list:REG_DEAD (reg/i:SI 3 r3) (nil))) (note 29 25 0 0 NOTE_INSN_BLOCK_END) Later on around line 2250: /* We now know that we can do this combination. Merge the insns and update the status of registers and LOG_LINKS. */ { rtx i3notes, i2notes, i1notes = 0; newi2pat is NULL here and newpat is: (gdb) p debug_rtx(newpat) (set (reg:SI 86) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1]))) So I believe something already has gone wrong til here. If somebody can give me a hint where to look closer from here... Otherwise I'm lost in this megafunction. Franz. From gcc-return-9157-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 22:07:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20478 invoked by alias); 16 Aug 1999 22:07:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20435 invoked from network); 16 Aug 1999 22:06:52 -0000 Received: from cg667526-a.adubn1.nj.home.com (HELO drow.them.org) (mail@24.2.213.175) by egcs.cygnus.com with SMTP; 16 Aug 1999 22:06:52 -0000 Received: from drow by drow.them.org with local (Exim 3.02 #1 (Debian)) id 11GUwl-0000Bc-00; Mon, 16 Aug 1999 18:09:39 -0400 Date: Mon, 16 Aug 1999 18:09:39 -0400 From: Daniel Jacobowitz To: gcc@gcc.gnu.org Subject: Re: Cross Compiling Message-ID: <19990816180939.A588@them.org> Mail-Followup-To: gcc@gcc.gnu.org References: <22898.934835744@upchuck.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.12i In-Reply-To: <22898.934835744@upchuck.cygnus.com>; from Jeffrey A Law on Mon, Aug 16, 1999 at 02:35:44PM -0600 On Mon, Aug 16, 1999 at 02:35:44PM -0600, Jeffrey A Law wrote: > In message you write: > > I'm trying to build a cross-compiler from a Red Hat Linux system to a > > Cygwin system (this is actually the first of several cross-compilers I'm > > trying to build, so prebuilt packages won't help). Anyway, here is the > > process I'm going through > You have to provide header files and libraries for your target system. > Please read the installation instructions. > > jeff Is there any way to configure which will not require the libraries? For instance, if you have no library for the target system? Will libgcc build with just the headers for the target? This has become a FAQ, and the crossgcc document is badly in need of updates (which I would volunteer if I knew the answers). Dan /--------------------------------\ /--------------------------------\ | Daniel Jacobowitz |__| SCS Class of 2002 | | Debian GNU/Linux Developer __ Carnegie Mellon University | | dan@debian.org | | dmj+@andrew.cmu.edu | \--------------------------------/ \--------------------------------/ From gcc-return-9158-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 22:12:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22603 invoked by alias); 16 Aug 1999 22:12:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22566 invoked from network); 16 Aug 1999 22:11:55 -0000 Received: from thor.xraylith.wisc.edu (198.150.6.11) by egcs.cygnus.com with SMTP; 16 Aug 1999 22:11:55 -0000 Received: from mercury.xraylith.wisc.edu (mercury.xraylith.wisc.edu [128.104.182.221]) by thor.xraylith.wisc.edu (8.9.1a/8.9.1) with ESMTP id RAA06308; Mon, 16 Aug 1999 17:11:49 -0500 Received: from mercury.xraylith.wisc.edu (localhost [127.0.0.1]) by mercury.xraylith.wisc.edu (8.8.7/8.8.7) with ESMTP id RAA15564; Mon, 16 Aug 1999 17:11:40 -0500 Message-Id: <199908162211.RAA15564@mercury.xraylith.wisc.edu> To: Daniel Jacobowitz cc: gcc@gcc.gnu.org Subject: Re: Cross Compiling In-Reply-To: Your message of "Mon, 16 Aug 1999 18:09:39 EDT." <19990816180939.A588@them.org> Date: Mon, 16 Aug 1999 17:11:40 -0500 From: Mumit Khan Daniel Jacobowitz writes: > Is there any way to configure which will not require the libraries? > For instance, if you have no library for the target system? > > Will libgcc build with just the headers for the target? Depends on the target. You may not be able to build libgcc.a when cross-compiling for some targets; for others, having just the target headers will suffice. > This has become a FAQ, and the crossgcc document is badly in need of > updates (which I would volunteer if I knew the answers). You may want to check out the various howtos at http://www.xraylith.wisc.edu/~khan/software/gnu-win32/ The linux->cygwin cross assumes you have the Cygwin development tree already installs. If you look at the linux->mingw howto, it shows how and what to install for the target environment (headers/libs); the latest one, cygwin->linux, gives more details. Regards, Mumit From gcc-return-9159-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 22:22:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24520 invoked by alias); 16 Aug 1999 22:21:52 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24497 invoked from network); 16 Aug 1999 22:21:20 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 16 Aug 1999 22:21:20 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id QAA23302; Mon, 16 Aug 1999 16:16:38 -0600 X-Mailer: exmh version 2.0.2 To: Daniel Jacobowitz cc: gcc@gcc.gnu.org Subject: Re: Cross Compiling Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 16 Aug 1999 18:09:39 EDT. <19990816180939.A588@them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Aug 1999 16:16:38 -0600 Message-ID: <23299.934841798@upchuck.cygnus.com> From: Jeffrey A Law In message <19990816180939.A588@them.org>you write: > Is there any way to configure which will not require the libraries? > For instance, if you have no library for the target system? No. The autoconf mechanisms for libiberty, libstdc++, libf2c, libobjc require system libraries. > Will libgcc build with just the headers for the target? Yes. jeff From gcc-return-9160-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 22:55:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28533 invoked by alias); 16 Aug 1999 22:54:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28516 invoked from network); 16 Aug 1999 22:54:51 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 16 Aug 1999 22:54:51 -0000 Received: (qmail 28964 invoked by alias); 16 Aug 1999 22:54:45 -0000 Received: (qmail 28953 invoked from network); 16 Aug 1999 22:54:44 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 16 Aug 1999 22:54:44 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id XAA02643; Mon, 16 Aug 1999 23:54:17 +0100 From: Joern Rennecke Message-Id: <199908162254.XAA02643@phal.cygnus.co.uk> Subject: Re: Deadly optimization bug (all gcc versions!) In-Reply-To: <99081623444200.00809@ns1102.munich.netsurf.de> from Franz Sirl at "Aug 16, 1999 11:32:27 pm" To: Franz.Sirl-kernel@lauterbach.com (Franz Sirl) Date: Mon, 16 Aug 1999 23:54:17 +0100 (BST) Cc: dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > After the call to try_combine the instructions are deleted. try_combine is > entered with: > (gdb) p debug_rtx(i3) > > (insn 22 20 24 (set (reg:SI 86) > (lshiftrt:SI (reg:SI 3 r3) > (const_int 1 [0x1]))) 52 {*addsi3_internal1} (insn_list 14 (insn_list 20 (nil))) > (expr_list:REG_DEAD (reg/v:SI 85) > (expr_list:REG_DEAD (reg:SI 87) > (nil)))) > $134 = void > (gdb) p debug_rtx(i2) > > (insn 20 17 22 (set (reg:SI 87) > (lshiftrt:SI (reg/v:SI 84) > (const_int 1 [0x1]))) 211 {lshrsi3_no_power} (insn_list 17 (nil)) > (expr_list:REG_DEAD (reg/v:SI 84) > (nil))) > $135 = void > (gdb) p debug_rtx(i1) > > (insn 14 11 17 (set (reg/v:SI 85) > (lshiftrt:SI (reg:SI 3 r3) > (const_int 1 [0x1]))) 211 {lshrsi3_no_power} (nil) > (expr_list:REG_DEAD (reg:SI 3 r3) > (nil))) try_combine assumes that i2 feeds i3, and i1 feeds i2 and/or i3. This is clearly not the case here, the the call is in error. Look for the cause, probably some bogus LOG_LINKS. From gcc-return-9161-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 23:17:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31121 invoked by alias); 16 Aug 1999 23:17: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31103 invoked from network); 16 Aug 1999 23:17:47 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 16 Aug 1999 23:17:47 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id QAA09148 for ; Mon, 16 Aug 1999 16:10:42 -0700 Message-Id: <199908162310.QAA09148@zack.bitmover.com> To: gcc@gcc.gnu.org Subject: RTL type checking and '0' format codes Date: Mon, 16 Aug 1999 16:10:42 -0700 From: Zack Weinberg I have been looking into implementing type checking for RTL, much like the type checking for trees we already have. The various XFOO macros would check the slot against the format, and abort if it was invalid. '0' format codes cause problems. '0' is documented to mean that the slot is only valid in a specific pass, and should be ignored otherwise. They aren't initialized in gen_rtx_FOO, and they're ignored in generic copy-or-examine-RTL code. Most '0' slots are always addressed with a specific type, but the information on their type isn't in the format. LABEL_NUSES, JUMP_LABEL, LABEL_REFS, LABEL_NEXTREF, and CONTAINING_INSN are like this. We would like to type check them. In NOTEs, '0' means that the slot can contain any of five different things depending on what sort of NOTE it is. In ADDRESSOF, '0' is used because someone was too lazy to fix everything to understand 't'. :) What I'd like to do is eliminate '0' in favor of a set of codes that carry type info and indicate that this slot is only valid sometimes. We need analogues for 's', 'i', and 'e'. We also need a type code for bb info. I'd use 'F', 'I', 'R', and 'B' respectively (F for file, R for reference). In addition, I want to replace NOTE with a family of RTL types, one for each possible meaning of a negative NOTE_LINE_NUMBER. This is a fairly major undertaking, but doesn't require great skill, and I've already found a few bugs while doing the feasibility study. The benefits of type-checking RTL are obvious. Comments? zw From gcc-return-9162-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 23:27:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32126 invoked by alias); 16 Aug 1999 23:26:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32111 invoked from network); 16 Aug 1999 23:26:56 -0000 Received: from joshua.math.ucla.edu (@128.97.70.250) by egcs.cygnus.com with SMTP; 16 Aug 1999 23:26:56 -0000 Received: from pobox.com (dhcp-70-1.math.ucla.edu [128.97.70.201]) by joshua.math.ucla.edu (8.8.8/8.8.8) with ESMTP id QAA16846; Mon, 16 Aug 1999 16:26:51 -0700 (PDT) Message-ID: <37B89E2E.E173411A@pobox.com> Date: Mon, 16 Aug 1999 16:26:38 -0700 From: Paul Burchard X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mike Stump CC: gcc@gcc.gnu.org Subject: Re: surprising optimization results References: <199908161742.KAA16388@kankakee.wrs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Stump wrote: > Glad you noticed the cool codegen strategies in the compiler. Yes, actually the new LCM stuff may be the most impressive (at least I think that's what I'm seeing)... I can often do better by leaving duplicate expressions in the code, than by manually caching the same result in a local variable. -- ---------------------------------------------------------------------- Paul Burchard http://www.pobox.com/~burchard/ ---------------------------------------------------------------------- From gcc-return-9163-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 23:27:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 40 invoked by alias); 16 Aug 1999 23:27:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13 invoked from network); 16 Aug 1999 23:27:47 -0000 Received: from joshua.math.ucla.edu (@128.97.70.250) by egcs.cygnus.com with SMTP; 16 Aug 1999 23:27:47 -0000 Received: from pobox.com (dhcp-70-1.math.ucla.edu [128.97.70.201]) by joshua.math.ucla.edu (8.8.8/8.8.8) with ESMTP id QAA16903; Mon, 16 Aug 1999 16:27:13 -0700 (PDT) Message-ID: <37B86FF8.681E2587@pobox.com> Date: Mon, 16 Aug 1999 13:09:28 -0700 From: Paul Burchard X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Joe Buck CC: gcc@gcc.gnu.org Subject: Re: surprising optimization results References: <199908161330.GAA05556@atrus.synopsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joe Buck wrote: > Inline functions in gcc suffer because gcc makes a decision too early > about what needs to go into memory. In this case, I believe it is because > the arguments have their addresses taken, they are forced to memory. > After inlining, arguably there is no longer any object that has its > address taken.. But often the generated code still has dead stores > in it (structs or classes written to memory and never read back). Thanks, it helps to know that this could be a general effect (and not merely the usual confluence of myriad details affecting optimization). I'm a little surprised that call-by-reference is always interpreted as call-by-pointer-value, but I guess you're saying that's a reasonable implementation technique, as long as you have good dead-store analysis. Const reference arguments, by the way, seem to be handled differently (or at least the dead-store analysis has an easier time removing the extra layer of indirection). They are as efficient as by-value scalar arguments in every test I've tried. -- ---------------------------------------------------------------------- Paul Burchard http://www.pobox.com/~burchard/ ---------------------------------------------------------------------- From gcc-return-9164-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 16 23:38:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1299 invoked by alias); 16 Aug 1999 23:38:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1266 invoked from network); 16 Aug 1999 23:38:45 -0000 Received: from linuxpc1.lauterbach.com (qmailr@194.195.165.177) by egcs.cygnus.com with SMTP; 16 Aug 1999 23:38:45 -0000 Received: (qmail 732 invoked from network); 16 Aug 1999 23:38:40 -0000 Received: from ns1155.munich.netsurf.de (HELO ns1102.munich.netsurf.de) (195.180.235.155) by linuxpc1 with SMTP; 16 Aug 1999 23:38:40 -0000 From: Franz Sirl To: Joern Rennecke Subject: Re: Deadly optimization bug (all gcc versions!) Date: Tue, 17 Aug 1999 01:25:00 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com References: <199908162254.XAA02643@phal.cygnus.co.uk> In-Reply-To: <199908162254.XAA02643@phal.cygnus.co.uk> MIME-Version: 1.0 Message-Id: <99081701395000.00901@ns1102.munich.netsurf.de> Content-Transfer-Encoding: 8bit Am Die, 17 Aug 1999 schrieb Joern Rennecke: >> After the call to try_combine the instructions are deleted. try_combine is >> entered with: >> (gdb) p debug_rtx(i3) >> >> (insn 22 20 24 (set (reg:SI 86) >> (lshiftrt:SI (reg:SI 3 r3) >> (const_int 1 [0x1]))) 52 {*addsi3_internal1} (insn_list 14 (insn_list 20 (nil))) >> (expr_list:REG_DEAD (reg/v:SI 85) >> (expr_list:REG_DEAD (reg:SI 87) >> (nil)))) >> $134 = void >> (gdb) p debug_rtx(i2) >> >> (insn 20 17 22 (set (reg:SI 87) >> (lshiftrt:SI (reg/v:SI 84) >> (const_int 1 [0x1]))) 211 {lshrsi3_no_power} (insn_list 17 (nil)) >> (expr_list:REG_DEAD (reg/v:SI 84) >> (nil))) >> $135 = void >> (gdb) p debug_rtx(i1) >> >> (insn 14 11 17 (set (reg/v:SI 85) >> (lshiftrt:SI (reg:SI 3 r3) >> (const_int 1 [0x1]))) 211 {lshrsi3_no_power} (nil) >> (expr_list:REG_DEAD (reg:SI 3 r3) >> (nil))) > >try_combine assumes that i2 feeds i3, and i1 feeds i2 and/or i3. >This is clearly not the case here, the the call is in error. >Look for the cause, probably some bogus LOG_LINKS. Argh, sorry. I did not backscroll far enough, the correct i3,i2,i1 at the beginning are: (gdb) p debug_rtx(i3) (insn 22 20 24 (set (reg:SI 86) (plus:SI (reg/v:SI 85) (reg:SI 87))) 52 {*addsi3_internal1} (insn_list 14 (insn_list 20 (nil))) (expr_list:REG_DEAD (reg/v:SI 85) (expr_list:REG_DEAD (reg:SI 87) (nil)))) $181 = void (gdb) p debug_rtx(i2) (insn 14 11 17 (set (reg/v:SI 85) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1]))) 211 {lshrsi3_no_power} (nil) (expr_list:REG_DEAD (reg:SI 3 r3) (nil))) $182 = void (gdb) p debug_rtx(i1) (insn 20 17 22 (set (reg:SI 87) (lshiftrt:SI (reg/v:SI 84) (const_int 1 [0x1]))) 211 {lshrsi3_no_power} (insn_list 17 (nil)) (expr_list:REG_DEAD (reg/v:SI 84) (nil))) $183 = void So the feed rules are fulfilled. In the meantime I believe I narrowed it down a bit to this code around line 1740: /* If we already got a failure, don't try to do more. Otherwise, try to substitute in I1 if we have it. */ if (i1 && GET_CODE (newpat) != CLOBBER) { /* Before we can do this substitution, we must redo the test done above (see detailed comments there) that ensures that I1DEST isn't mentioned in any SETs in NEWPAT that are field assignments. */ if (! combinable_i3pat (NULL_RTX, &newpat, i1dest, NULL_RTX, 0, NULL_PTR)) { undo_all (); return 0; } n_occurrences = 0; subst_low_cuid = INSN_CUID (i1); newpat = subst (newpat, i1dest, i1src, 0, 0); undobuf.previous_undos = undobuf.undos; } Before the call to subst newpat/i1dest/i1src look like: (gdb) p debug_rtx(newpat) (set (reg:SI 86) (plus:SI (lshiftrt:SI (reg/v:SI 84) (const_int 1 [0x1])) (reg/v:SI 85))) $184 = void (gdb) p debug_rtx(i1dest) (reg/v:SI 85) $185 = void (gdb) p debug_rtx(i1src) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1])) which looks quite reasonable for newpat (I'm not sure about i1dest/i1src). But after subst() newpat looks like: (gdb) p debug_rtx(newpat) (set (reg:SI 86) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1]))) Franz. From gcc-return-9165-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 01:14:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10956 invoked by alias); 17 Aug 1999 01:14:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10941 invoked from network); 17 Aug 1999 01:14:23 -0000 Received: from x0185.lynchburg.net (HELO lynchburg.net) (bmbeach@216.207.178.205) by egcs.cygnus.com with SMTP; 17 Aug 1999 01:14:23 -0000 Received: from localhost (bmbeach@localhost) by lynchburg.net (8.8.5/8.8.3) with SMTP id QAA00308 for ; Mon, 16 Aug 1999 16:12:55 -0500 Date: Mon, 16 Aug 1999 16:12:50 -0500 (CDT) From: Bruce M Beach To: gcc@gcc.gnu.org Subject: GCC Build Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello gcc I have gcc-2.95 which builds and installs okay. What I am trying to do is install it on a bootable drive that is mounted as /system2 on the first drive(system1). i.e. install into /system2/usr/local/ on hdb2. I then reboot with the second drive (hdc2) mounted as "/" so that theoretically I should now have a gcc system installed in /usr/local etc. I have played with --prefix and --exec_prefix but am not sure what is happening. Compiling a simple program # gcc -o test_c test-c.c times out with # unable to load interpreter # cpp:internal compiler : program cpp got fatal signal 11 # gcc --help and # cpp --help return the usual help messages. test_c compiled on system1 and executed on system2 works fine # test_c Hello World Any information ,a pointer to where to direct this kind of question or suggested reading would be helpful. Bruce Beach bmbeach@lynchburg.net From gcc-return-9166-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 01:42:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15730 invoked by alias); 17 Aug 1999 01:42:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15701 invoked from network); 17 Aug 1999 01:42:43 -0000 Received: from cg667526-a.adubn1.nj.home.com (HELO drow.them.org) (mail@24.2.213.175) by egcs.cygnus.com with SMTP; 17 Aug 1999 01:42:43 -0000 Received: from drow by drow.them.org with local (Exim 3.02 #1 (Debian)) id 11GYJe-0000gg-00; Mon, 16 Aug 1999 21:45:30 -0400 Date: Mon, 16 Aug 1999 21:45:30 -0400 From: Daniel Jacobowitz To: gcc@gcc.gnu.org Subject: Re: Cross Compiling Message-ID: <19990816214530.A2623@them.org> Mail-Followup-To: gcc@gcc.gnu.org References: <19990816180939.A588@them.org> <23299.934841798@upchuck.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.12i In-Reply-To: <23299.934841798@upchuck.cygnus.com>; from Jeffrey A Law on Mon, Aug 16, 1999 at 04:16:38PM -0600 On Mon, Aug 16, 1999 at 04:16:38PM -0600, Jeffrey A Law wrote: > In message <19990816180939.A588@them.org>you write: > > Is there any way to configure which will not require the libraries? > > For instance, if you have no library for the target system? > No. The autoconf mechanisms for libiberty, libstdc++, libf2c, libobjc > require system libraries. Hm, but is it possible to build a target C compiler without a target libiberty (obviously you'd need a host libiberty but that isn't a problem)? > > Will libgcc build with just the headers for the target? > Yes. > > > jeff > > > Dan /--------------------------------\ /--------------------------------\ | Daniel Jacobowitz |__| SCS Class of 2002 | | Debian GNU/Linux Developer __ Carnegie Mellon University | | dan@debian.org | | dmj+@andrew.cmu.edu | \--------------------------------/ \--------------------------------/ From gcc-return-9167-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 01:46:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17391 invoked by alias); 17 Aug 1999 01:46:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17346 invoked from network); 17 Aug 1999 01:46:16 -0000 Received: from motgate2.mot.com (129.188.136.102) by egcs.cygnus.com with SMTP; 17 Aug 1999 01:46:16 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [129.188.137.195]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id UAA15324 for ; Mon, 16 Aug 1999 20:46:55 -0500 (CDT)] Received: [from latour.rsch.comm.mot.com (latour.rsch.comm.mot.com [145.1.80.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id UAA20741 for ; Mon, 16 Aug 1999 20:46:15 -0500 (CDT)] Received: (from rittle@localhost) by latour.rsch.comm.mot.com (8.9.3/8.9.3) id UAA36010; Mon, 16 Aug 1999 20:46:14 -0500 (CDT) (envelope-from rittle) Date: Mon, 16 Aug 1999 20:46:14 -0500 (CDT) From: Loren James Rittle Message-Id: <199908170146.UAA36010@latour.rsch.comm.mot.com> To: gcc@gcc.gnu.org Subject: Standardization of compiling and linking multi-threaded applications Reply-to: rittle@rsch.comm.mot.com Open message to gcc port maintainers (and port users if you compile and link multi-threaded applications): If a gcc port has been configured with --enable-threads=posix (or --enable-threads=pthreads, or if the port naturally configures such support in), then is there any common agreement on the command line switch that users should provide to compile and link a multi-threaded application? Should there be standardization across platforms in this area? If a gcc port has been configured with --enable-threads (assume for the moment that the system default is not posix threads), then is there any common agreement on the command line switch that users should provide to compile and link a multi-threaded application? Should there be standardization across platforms when the underlying threading package might be different? My study reveals that some ports use -pthread while others use -pthreads, -mthreads or -threads. Thus, it appears that there is little standardization between gcc ports when it comes to exact name of the command-line switch to hint to the compiler that the user is compiling and linking a multi-threaded application. This appears to be true even when the platforms are all using POSIX threads. At least one port (FreeBSD) uses -pthread to refer to user-level POSIX threads and -kthread to refer to kernel-level POSIX threads. Another port (Solaris) uses -threads when Solaris threads were configured and -pthreads when POSIX threads; but the written spec file doesn't catch a mismatch (and granted in most/all versions of Solaris, this might not be a problem). It would be great if we could all agree on a particular mapping with additional mappings, if the target supported additional threading libraries or modes completely compatible with the way it was configured. Thus, a port might always support -threads, if it was configured with --enable-threads. It could support any of the existing switch names or additional switch names as required to offer the additional mappings. It would also be nice if the standardized switches produced an error whenever they were provided but gcc was not configured and built with multi-threading support. As it stands now, some language users can provide the switch even when gcc was built with --enable-threads=no and will be quite surprised by an unstable system at run-time. If you are a port user or port maintainer with a position on this issue, please send me e-mail. Feel free to CC the list if I missed a very important point, but I will summerize to the list. I am particularly interested in whether users want the existing switch names to be maintained; or wouldn't mind converting to a new scheme that was standardized across all platforms. Assuming that a strong majority is in favor of such standardized, it would be my intention to provide patches for all system configurations that currently support threads and documentation on how to use the feature as a user (since only -mthreads appears to be documented in the info files). Regards, Loren From gcc-return-9168-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 01:54:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19835 invoked by alias); 17 Aug 1999 01:54:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19819 invoked from network); 17 Aug 1999 01:54:47 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 17 Aug 1999 01:54:47 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id SAA09697; Mon, 16 Aug 1999 18:47:40 -0700 Message-Id: <199908170147.SAA09697@zack.bitmover.com> To: Kevin Atkinson cc: gcc@gcc.gnu.org Subject: Re: Recursion Optimization In-Reply-To: Message from Kevin Atkinson of "Mon, 16 Aug 1999 14:50:43 EDT." <37B85D83.79E0FC67@home.com> Date: Mon, 16 Aug 1999 18:47:40 -0700 From: Zack Weinberg Kevin Atkinson wrote: > Zack Weinberg wrote: > > > > ... To answer the original question: No, GCC is not capable of any of these > > optimizations. I'm sure we would be delighted to accept contributions > > that gave it the ability to do them. Even adding support for general > > tail recursion optimization a la Scheme would be a great step > > forward. > > > > There is existing support for tail recursion optimization in very > > limited cases. I have never got it to do anything useful for non-toy > > functions. > > Has anyone tried writing a front end for a functional language like ML > or even Haskell for gcc. Not to my knowledge. Someone else might know better. The sensible place to do this sort of optimization would be in the tree structures generated by the front end, before their conversion to RTL. We currently have very few optimizations at this point and they are mostly language-specific, so an ML front end might not translate to improvements for C. Before tackling tree optimizations, you would have to convert all the front ends of interest to build one tree for each function instead of one tree for each statement. This is being done for C++ but not for other languages. (Mark: will your work apply to C as well as C++?) zw From gcc-return-9169-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 05:01:23 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6950 invoked by alias); 17 Aug 1999 05:01:21 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6552 invoked from network); 17 Aug 1999 04:59:24 -0000 Received: from unknown (HELO sanat.shirazu.ac.ir) (194.225.37.2) by egcs.cygnus.com with SMTP; 17 Aug 1999 04:59:24 -0000 Received: from localhost (admin@localhost) by sanat.shirazu.ac.ir (8.8.7/8.8.7) with SMTP id IAA15646 for ; Tue, 17 Aug 1999 08:11:57 +0430 Date: Tue, 17 Aug 1999 08:11:57 +0430 (IRST) From: admin To: gcc@gcc.gnu.org Subject: Printing Color Characters on Linux Console Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi 1)I want to write color characters on linux console. I wanted to know if there is somethings like gotoxy() , textcolor() and cprintf() of borland c in gcc ?I need both locating and color printing functions. 2)I want to lock files , as I read in Steven's Book on Network Programming there are two functions lockf() and flock() but I think none of them exists in gcc. Am I to use other methods 3)What about BSD Sockets , does gcc use them ? With regards , Siamak Sarmady From gcc-return-9170-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 05:05:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8520 invoked by alias); 17 Aug 1999 05:04:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8505 invoked from network); 17 Aug 1999 05:04:57 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 17 Aug 1999 05:04:57 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990817050455.MPOE9770.mail.rdc1.md.home.com@home.com>; Mon, 16 Aug 1999 22:04:55 -0700 Message-ID: <37B8EDFA.1FC0181E@home.com> Date: Tue, 17 Aug 1999 01:07:06 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: Zack Weinberg CC: gcc@gcc.gnu.org Subject: Re: Recursion Optimization References: <199908161800.LAA25487@zack.bitmover.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zack Weinberg wrote: > > where push, pop, and stack_empty are operations on some generic stack. > By doing this, you avoid having to push "stop", the return address, > the frame pointer, any call-saved registers, and so on. It can be a > *huge* win in terms of stack usage. What about speed, assuming there is enough memory? -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-9171-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 05:47:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15544 invoked by alias); 17 Aug 1999 05:46:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15527 invoked from network); 17 Aug 1999 05:46:51 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 17 Aug 1999 05:46:51 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id CAA11972; Tue, 17 Aug 1999 02:22:11 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id CAA27745; Tue, 17 Aug 1999 02:22:04 -0300 (EST) To: admin Cc: gcc@gcc.gnu.org Subject: Re: Printing Color Characters on Linux Console References: From: Alexandre Oliva Date: 17 Aug 1999 02:26:00 -0300 In-Reply-To: admin's message of "Tue, 17 Aug 1999 08:11:57 +0430 (IRST)" Message-ID: Lines: 28 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 17, 1999, admin wrote: > 1)I want to write color characters on linux console. I wanted to know if > there is somethings like gotoxy() , textcolor() and cprintf() of borland c > in gcc? I need both locating and color printing functions. This is not a C *compiler* issue, it's a *library* issue, and gcc doesn't contain a C library and, even if it did, it probably wouldn't provide such functionality, since the GNU C Library doesn't. For the functionality you want, you should probably take a look at libraries such as termcap or ncurses. > 2) I want to lock files , as I read in Steven's Book on Network > Programming there are two functions lockf() and flock() but I think > none of them exists in gcc. Both are implemented in the GNU C Library and in the Linux kernel. > 3)What about BSD Sockets , does gcc use them ? No, but it will let you call functions in the C library that implement them. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9172-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 06:07:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20223 invoked by alias); 17 Aug 1999 06:07:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20206 invoked from network); 17 Aug 1999 06:07:26 -0000 Received: from thor.xraylith.wisc.edu (198.150.6.11) by egcs.cygnus.com with SMTP; 17 Aug 1999 06:07:26 -0000 Received: from mercury.xraylith.wisc.edu (mercury.xraylith.wisc.edu [128.104.182.221]) by thor.xraylith.wisc.edu (8.9.1a/8.9.1) with ESMTP id BAA07487 for ; Tue, 17 Aug 1999 01:07:18 -0500 Received: from mercury.xraylith.wisc.edu (localhost [127.0.0.1]) by mercury.xraylith.wisc.edu (8.8.7/8.8.7) with ESMTP id BAA10705 for ; Tue, 17 Aug 1999 01:07:10 -0500 Message-Id: <199908170607.BAA10705@mercury.xraylith.wisc.edu> To: gcc@gcc.gnu.org Subject: gcc link_command_spec question (possible bug?) Date: Tue, 17 Aug 1999 01:07:10 -0500 From: Mumit Khan The link_command_spec entry contains the following: static const char *link_command_spec = "\ %{!fsyntax-only: \ %{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} \ %{r} %{s} %{t} %{u*} %{x} %{z} %{Z}\ %{!A:%{!nostdlib:%{!nostartfiles:%S}}}\ %{static:} %{L*} %D %o\ %{!nostdlib:%{!nodefaultlibs:%G %L %G}}\ %{!A:%{!nostdlib:%{!nostartfiles:%E}}}\ %{T*}\ \n }}}}}}"; ^^^ Does the \n belong there? Regards, Mumit From gcc-return-9173-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 06:15:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21909 invoked by alias); 17 Aug 1999 06:15:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21887 invoked from network); 17 Aug 1999 06:15:40 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 17 Aug 1999 06:15:40 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.8.7/8.8.7) with ESMTP id XAA17445; Mon, 16 Aug 1999 23:19:32 -0700 To: zack@bitmover.com Cc: kevinatk@home.com, gcc@gcc.gnu.org Subject: Re: Recursion Optimization In-Reply-To: <199908170147.SAA09697@zack.bitmover.com> References: <199908170147.SAA09697@zack.bitmover.com> X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990816231932V.mitchell@codesourcery.com> Date: Mon, 16 Aug 1999 23:19:32 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 17 >>>>> "Zack" == Zack Weinberg writes: Zack> Before tackling tree optimizations, you would have to Zack> convert all the front ends of interest to build one tree for Zack> each function instead of one tree for each statement. This Zack> is being done for C++ but not for other languages. (Mark: Zack> will your work apply to C as well as C++?) Not directly. But, in the long term, it is my opinion that the C front-end and the C++ front-end should merge, or at least share a tremendous amount of common code. At that point, C would benefit. I'm hoping that my work will incentivize people to work in that direction. :-) -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-9174-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 07:00:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31101 invoked by alias); 17 Aug 1999 07:00:29 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31039 invoked from network); 17 Aug 1999 07:00:26 -0000 Received: from dialup125.albatross.co.nz (HELO loki.albatross.co.nz) (nobody@203.97.5.125) by egcs.cygnus.com with SMTP; 17 Aug 1999 07:00:26 -0000 Received: from localhost (psycho@localhost) by loki.albatross.co.nz (8.9.3/8.9.3) with ESMTP id TAA18586; Tue, 17 Aug 1999 19:02:04 +1200 X-Authentication-Warning: loki.albatross.co.nz: psycho owned process doing -bs Date: Tue, 17 Aug 1999 19:02:04 +1200 (NZST) From: Keith Duthie To: Bruce M Beach cc: gcc@gcc.gnu.org Subject: Re: GCC Build In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 16 Aug 1999, Bruce M Beach wrote: > # cpp:internal compiler : program cpp got fatal signal 11 Probably a hardware problem. Check out http://www.bitwizard.nl/sig11/ -- Understanding is a three edged sword. Do you *want* to get the point? http://www.albatross.co.nz/~psycho/ O- From gcc-return-9175-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 08:27:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15584 invoked by alias); 17 Aug 1999 08:27:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15565 invoked from network); 17 Aug 1999 08:27:47 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 17 Aug 1999 08:27:47 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id 97C8832DB6; Tue, 17 Aug 1999 10:27:20 +0200 (MEST) Received: from Wotan.suse.de (Wotan.suse.de [10.10.0.1]) by Galois.suse.de (Postfix) with ESMTP id 31F6067A9; Tue, 17 Aug 1999 10:27:19 +0200 (MEST) Received: from hawking.suse.de (Hawking.suse.de [10.10.0.89]) by Wotan.suse.de (Postfix) with ESMTP id 95CEE7F8B; Tue, 17 Aug 1999 10:27:18 +0200 (MEST) Received: (from schwab@localhost) by hawking.suse.de (8.9.3/8.9.3) id KAA00902; Tue, 17 Aug 1999 10:27:12 +0200 To: Mumit Khan Cc: gcc@gcc.gnu.org Subject: Re: gcc link_command_spec question (possible bug?) References: <199908170607.BAA10705@mercury.xraylith.wisc.edu> X-Yow: Oh, FISH sticks, CHEEZ WHIZ, GIN fizz, SHOW BIZ!! From: Andreas Schwab Date: 17 Aug 1999 10:27:12 +0200 In-Reply-To: Mumit Khan's message of "Tue, 17 Aug 1999 01:07:10 -0500" Message-ID: Lines: 25 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Mumit Khan writes: |> The link_command_spec entry contains the following: |> |> static const char *link_command_spec = "\ |> %{!fsyntax-only: \ |> %{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} \ |> %{r} %{s} %{t} %{u*} %{x} %{z} %{Z}\ |> %{!A:%{!nostdlib:%{!nostartfiles:%S}}}\ |> %{static:} %{L*} %D %o\ |> %{!nostdlib:%{!nodefaultlibs:%G %L %G}}\ |> %{!A:%{!nostdlib:%{!nostartfiles:%E}}}\ |> %{T*}\ |> \n }}}}}}"; |> ^^^ |> |> Does the \n belong there? Yes, it is significant. It tells the specs parser to actually start the command. See gcc.c:do_spec_1, around line 3433 in the current cvs. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg From gcc-return-9176-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 09:50:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24971 invoked by alias); 17 Aug 1999 09:50:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24946 invoked from network); 17 Aug 1999 09:50:23 -0000 Received: from guardian.hermes.si (193.77.5.150) by egcs.cygnus.com with SMTP; 17 Aug 1999 09:50:23 -0000 Received: from hermes.si (primus.hermes.si [193.77.5.98]) by guardian.hermes.si (8.9.3/8.9.3) with ESMTP id KAA03089; Tue, 17 Aug 1999 10:27:24 +0200 (METDST) Received: from lux.hermes.si (lux.hermes.si [10.17.4.137]) by hermes.si (8.9.3/8.9.3) with SMTP id KAA05581; Tue, 17 Aug 1999 10:27:16 +0200 (METDST) Received: from hermes.si by lux.hermes.si (SMI-8.6/SMI-SVR4) id KAA00358; Tue, 17 Aug 1999 10:27:09 +0200 Message-ID: <37B91CE4.E9034CA3@hermes.si> Date: Tue, 17 Aug 1999 10:27:16 +0200 From: Branko Cibej Organization: HERMES SoftLab X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: sl,en-GB,en MIME-Version: 1.0 To: Zack Weinberg CC: Kevin Atkinson , gcc@gcc.gnu.org Subject: Re: Recursion Optimization References: <199908161800.LAA25487@zack.bitmover.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Zack Weinberg wrote: > A genius compiler would recognize that > the values pushed on the stack are predictable, and generate > > int sum(int i, int stop) > { > int tmp = 0; > while(i <= stop) tmp += i++; > return tmp; > } And a genius compiler who had also gone to school would recognise that as a sum of a sequence and generate int sum (int i, int stop) { return (stop * (stop + 1) - i * (i + 1)) / 2; } -- then get it wrong if i or stop are negative. That would be fixed in the next release, of course ;-) Brane -- Branko Èibej HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia voice: (+386 61) 186 53 49 fax: (+386 61) 186 52 70 From gcc-return-9177-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 11:00:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1175 invoked by alias); 17 Aug 1999 10:59:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1160 invoked from network); 17 Aug 1999 10:59:55 -0000 Received: from mobil.surnet.ru (root@195.54.2.7) by egcs.cygnus.com with SMTP; 17 Aug 1999 10:59:55 -0000 Received: (from uucgilh@localhost) by mobil.surnet.ru (8.9.1a/8.9.1) with UUCP id QAA14622 for egcs@egcs.cygnus.com; Tue, 17 Aug 1999 16:57:18 +0600 (UDT) Received: (from uucp@localhost) by cgilh.chel.su (8.8.7/8.8.7) with UUCP id HAA01720 for egcs@egcs.cygnus.com; Tue, 17 Aug 1999 07:49:00 +0600 Received: from localhost (ilia@localhost) by localhost.cgu.chel.su (8.9.2/8.9.2) with ESMTP id XAA01071 for ; Mon, 16 Aug 1999 23:15:39 +0600 (ESS) (envelope-from ilia@cgilh.chel.su) X-Authentication-Warning: localhost.cgu.chel.su: ilia owned process doing -bs Date: Mon, 16 Aug 1999 23:15:39 +0600 (ESS) From: Ilia Chipitsine X-Sender: ilia@localhost.cgu.chel.su To: egcs@egcs.cygnus.com Subject: again about MXUNIT in f2c library. In-Reply-To: <19990815234050.A21258@pcep-jamie.cern.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: 8BIT Guys (and of course girls) ! what if we add one line to the definition of unit structure in fio.h ? it could help us to remove MXUNIT later. something like ... typedef struct { FILE *ufd; /*0=unconnected*/ char *ufnm; int unit_number; /* yes, i mean this line */ #ifndef MSDOS long uinode; int udev; #endif int url; /*0=sequential*/ flag useek; /*true=can backspace, use dir, ...*/ flag ufmt; flag uprnt; flag ublnk; flag uend; flag uwrt; /*last io was write*/ flag uscrtch; } unit; Regards, (îÁÉÌÕÞÛÉÅ ÐÏÖÅÌÁÎÉÑ) Ilia Chipitsine (éÌØÑ ûÉÐÉÃÉÎ) From gcc-return-9178-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 12:26:17 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23846 invoked by alias); 17 Aug 1999 12:26:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23829 invoked from network); 17 Aug 1999 12:26:05 -0000 Received: from bubble.ndsuk.com (194.216.129.248) by egcs.cygnus.com with SMTP; 17 Aug 1999 12:26:05 -0000 Received: from SMTP (emma.hedge.ndsuk.com [172.17.253.25]) by bubble.ndsuk.com (8.8.7/8.8.7) with SMTP id MAA04881; Tue, 17 Aug 1999 12:25:55 GMT Received: from sage.hedge.ndsuk.com ([172.17.253.10]) by 172.17.253.25 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 17 Aug 1999 12:20:20 0000 (GMT) Received: from ibm.net (ndsuk4908.stone.ndsuk.com [172.16.195.75]) by sage.hedge.ndsuk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QW2HHZQD; Tue, 17 Aug 1999 13:25:53 +0100 Message-ID: <37B954D0.A71114AA@ibm.net> Date: Tue, 17 Aug 1999 13:25:52 +0100 From: Etienne Lorrain Organization: Protection of the "jnp" instruction league X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "H.J. Lu" CC: egcs@egcs.cygnus.com Subject: Re: binutils 2.9.5.0.7 is released. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello H.J., > This is the beta release of binutils 2.9.5.0.7 for Linux, which is > based on binutils 1999 0813 plus various changes. It is purely for > Linux, although it has been tested on Solaris/Sparc and Solaris/x86 > from time to time. > > I am planning to make the public release soon. Please test it as much > as you can. > > Please report any bugs related to binutils 2.9.5.0.7 to hjl@lucon.org. I noticed a feature with my software (gujin) on the linker side. This exists on RH 6 version of binutils and your lattest snapshot, but was not present on standart RH 5 distributions (early binutils-2.9.1). Simply, it is a gap of 0x10 bytes out of sections, i.e. in between .code and .data - and it seems to be unvolumtary (i.e. no alignment needed because it is already aligned). Here is the linker command file: >>>>>>>> boot.lnk SECTIONS { .text : { boot.o(.text) *(.text) *(.rodata) . = ALIGN (16) ; _end = .; } = 0 .data : { *(.data) *(.bss) *(COMMON) . = ALIGN (4); _edata = .; . = 112*512-SIZEOF(.text); } = 0 } <<<<<<<< I was assuming that ".data" start just after ".text", mostly because I have aligned "_end", so the calculus to fill the resulting binary file to a size of 112*512. The .map file contains: >>>>>>>> .rodata 0x000094e0 0x4f0 user.o 0x000099d0 .=ALIGN(0x10) 0x000099d0 _end=. .data 0x000099e0 0x4630 *(.data) <<<<<<<< i.e. there is a gap of 0x000099e0-0x000099d0 = 0x10 out of any section. I can modify my software without any problem, but this seems mostly strange so I think I had to report it (I am also doing full checksum calculus and things like that). If needed, I can provide the complete .tar.gz to reproduce it easily on RH6/egcs-1.1.2/binutils-2.9.5.0.7, or soon on RH6/gcc-2.95, but it is ~100Kb so not on the list. Thanks, Etienne. From gcc-return-9179-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 14:15:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15108 invoked by alias); 17 Aug 1999 14:15:15 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15076 invoked from network); 17 Aug 1999 14:15:12 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 17 Aug 1999 14:15:12 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id HAA20987; Tue, 17 Aug 1999 07:14:44 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id HAA03251; Tue, 17 Aug 1999 07:14:43 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id HAA00067; Tue, 17 Aug 1999 07:14:43 -0700 Message-Id: <199908171414.HAA00067@atrus.synopsys.com> Subject: Re: Recursion Optimization To: kevinatk@home.com (Kevin Atkinson) Date: Tue, 17 Aug 99 7:14:43 PDT Cc: gcc@gcc.gnu.org In-Reply-To: <37B7C021.4068385F@home.com>; from "Kevin Atkinson" at Aug 16, 99 3:39 am X-Mailer: ELM [version 2.3 PL11] > Does gcc optimize in any way to minimize the cost of recursive functions > calls. In particular: > > ONE: > > Does gcc optimize tail recursive functions into simple loops? Only in the special case of pure tail recursion (cases where, in effect, the call can be turned into a goto). Pure tail recursion isn't that common. > In a function call like this: > > int sum(int i, int stop) { > if (i == stop) return i; > else return sum(i+1, stop) + i; > } > > Will gcc recognize that the value of the second parameter never changes > so that it can avoid allocating multiple copies of it on the stack. No. From gcc-return-9180-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 14:29:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18506 invoked by alias); 17 Aug 1999 14:29:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18491 invoked from network); 17 Aug 1999 14:29:34 -0000 Received: from gov-1-47.gov.nf.ca (HELO MAIL.GOV.NF.CA) (209.128.28.47) by egcs.cygnus.com with SMTP; 17 Aug 1999 14:29:34 -0000 Received: from GOV_NF_PRIMARY-Message_Server by MAIL.GOV.NF.CA with Novell_GroupWise; Tue, 17 Aug 1999 12:10:10 -0230 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Tue, 17 Aug 1999 12:00:18 -0230 From: "Jason Pond" To: Subject: Installing gcc 2.95 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I posted this message earlier but i still haven't been successful in = installing GCC-2.95. I am sending it again with hopes that someone may be = able to help me out. I have just recently downloaded the latest and greatest GCC-2.95 but I am = having some difficulty installing it. I find the installation instructions= a bit confusing....I am by no means an expert in system administration so = that is likely the major problem. I am trying to install it on a SUN = ULTRA-2 with Solaris 2.6. However, when I try and configure, the scripts = fail and I can't seem to figure out why. I think that it may have = something to do with the setting of the CC environment variable. The following is the error message I receive after issuing this command ../gcc-2.95/configure --prefix=3D/usr1/gcc_tools Configuring for a sparc-sun-solaris2.6 host. Created "Makefile" in /usr1/gcc using "mh-frag" /usr/ucb/cc: language optional software package not installed *** The command '/usr/ucb/cc -o conftest -g conftest.c' failed. *** You must set the environment variable CC to a working compiler. >From what I can read from this message, I need a compiler in order to = install it??? However, I don't have a compiler.....thats the reason I am = installing it. Maybe I need a different download??=20 Does anyone have any ideas, or a more detailed installation procedure. Thanks Jason Pond Jason Pond Ecosystem Health Division Dept. of Forest Resources and Agrifoods Corner Brook, Nfld A2H 6J8 709-637-2507 (Tel) 709-637-2290 (Fax) Join the Global Association of Online Foresters - www.foresters.org From gcc-return-9181-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 14:44:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21121 invoked by alias); 17 Aug 1999 14:44:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20793 invoked from network); 17 Aug 1999 14:39:07 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 17 Aug 1999 14:39:07 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id LAA19005; Tue, 17 Aug 1999 11:32:27 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id LAA08587; Tue, 17 Aug 1999 11:32:31 -0300 (EST) To: "Jason Pond" Cc: Subject: Re: Installing gcc 2.95 References: From: Alexandre Oliva Date: 17 Aug 1999 11:36:27 -0300 In-Reply-To: "Jason Pond"'s message of "Tue, 17 Aug 1999 12:00:18 -0230" Message-ID: Lines: 24 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 17, 1999, "Jason Pond" wrote: > *** You must set the environment variable CC to a working compiler. > From what I can read from this message, I need a compiler in order > to install it??? That's right. > However, I don't have a compiler.....thats the reason I am > installing it. You need another compiler to build it. > Maybe I need a different download?? There are pre-compiled versions of gcc that you may download, for example, from www.sunfreeware.com. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9182-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 15:20:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24508 invoked by alias); 17 Aug 1999 15:20:37 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24493 invoked from network); 17 Aug 1999 15:20:33 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 17 Aug 1999 15:20:33 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with SMTP id LAA19513 for ; Tue, 17 Aug 1999 11:20:31 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com by world.std.com (TheWorld/Spike-2.0) id AA14045; Tue, 17 Aug 1999 11:18:33 -0400 Received: (qmail 26324 invoked by uid 500); 17 Aug 1999 15:00:51 -0000 Date: 17 Aug 1999 15:00:51 -0000 Message-Id: <19990817150051.26323.qmail@deer> To: ilia@cgilh.chel.su Cc: egcs@egcs.cygnus.com Cc: craig@jcb-sc.com In-Reply-To: (message from Ilia Chipitsine on Mon, 16 Aug 1999 23:15:39 +0600 (ESS)) Subject: Re: again about MXUNIT in f2c library. References: >Guys (and of course girls) ! > >what if we add one line to the definition of unit structure in fio.h ? >it could help us to remove MXUNIT later. I don't see enough explanation there as to what that added line would achieve. Isn't that structure what libI77 uses as the building-block for the f__units array, which is made MXUNIT elements long, and isn't that array *indexed* by the unit number? So what code, exactly, benefits from adding the unit number into the structure? I can imagine error-reporting might be better in layers below the libI77 interface itself, but I don't know whether there are any such layers (I mean that don't get the unit number anyway, but want to report errors -- especially since the interface layer probably sets a global variable identifying the unit number currently being processed). I've always assumed removing MXUNIT is pretty easy -- just add code to handle the case where the unit number is outside the range by looking into, and if necessary allocating more chunks to, a pool of `unit' structures for out-of-range unit numbers, or something like that. No need to change `unit' itself, unless you want a simple-minded linked list of out-of-range numbers (though that might be too slow for some applications). The hardest part is probably getting dmg to either do, or accept, such a patch in netlib's libf2c. I don't recommend libg2c-specific changes at this point. tq vm, (burley) From gcc-return-9183-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 16:54:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11022 invoked by alias); 17 Aug 1999 16:53:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10988 invoked from network); 17 Aug 1999 16:53:50 -0000 Received: from rasp2-53.lbl.gov (HELO ludwig) (131.243.212.153) by egcs.cygnus.com with SMTP; 17 Aug 1999 16:53:50 -0000 Received: from tiger.berkeley.edu (localhost [127.0.0.1]) by ludwig (8.9.3/8.9.3) with ESMTP id JAA04631 for ; Tue, 17 Aug 1999 09:54:21 -0400 Message-ID: <37B96984.C6551157@tiger.berkeley.edu> Date: Tue, 17 Aug 1999 09:54:12 -0400 From: David Roundy X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.6-15apmac ppc) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: installed gcc 2.95 successfully Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have successfully installed gcc 2.95 on my... powerpc-unknown-linux-gnu system, which happens to be a powermac 7300. David Roundy From gcc-return-9184-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 16:55:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11944 invoked by alias); 17 Aug 1999 16:55:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11887 invoked from network); 17 Aug 1999 16:55:20 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 17 Aug 1999 16:55:19 -0000 Received: from bolero.cs.tu-berlin.de (doko@bolero.cs.tu-berlin.de [130.149.19.1]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id SAA10750 for ; Tue, 17 Aug 1999 18:53:42 +0200 (MET DST) From: Matthias Klose Received: (from doko@localhost) by bolero.cs.tu-berlin.de (8.9.1/8.9.0) id SAA15176 for gcc@gcc.gnu.org; Tue, 17 Aug 1999 18:53:41 +0200 (MET DST) Date: Tue, 17 Aug 1999 18:53:41 +0200 (MET DST) Message-Id: <199908171653.SAA15176@bolero.cs.tu-berlin.de> To: gcc@gcc.gnu.org Subject: Index pages for mailing list archives >From the index pages you can only reach the date index for each mailing list. It would be nice to have something like - August, 1999 [Date Index] [Subject Index] [Author Index] [Thread Index] to go directly to each index. An alternative would be to skip these pages altogether, and provide a http://egcs.cygnus.com/lists.html which has direct pointers to the mailing list archives (like http://www.debian.org/Lists-Archives). Where can I find the mhonarc templates and scripts for the generation of the archives? From gcc-return-9185-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 17:01:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14781 invoked by alias); 17 Aug 1999 17:01:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14653 invoked from network); 17 Aug 1999 17:01:07 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 17 Aug 1999 17:01:07 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id TAA04346; Tue, 17 Aug 1999 19:00:18 +0200 (MET DST) Date: Tue, 17 Aug 1999 19:00:17 +0200 (MET DST) From: Gerald Pfeifer To: Brad Lucier cc: gcc-bugs@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: bug in testsuite FAQ entry? In-Reply-To: <199908022326.SAA27664@polya.math.purdue.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 2 Aug 1999, Brad Lucier wrote: > Is the online FAQ entry for how to run the testsuite with different flags > accurate? I couldn't get anything to work in tcsh until I reversed the > order of the two types of quotes: > > make RUNTESTFLAGS="--tool_opts '-mieee -mcpu=ev6'" check I didn't notice any comments on that, but if the FAQ is indeed wrong, we should change it as soon as possible, perhaps even in time for the release. Any comments from our testsuite gurus? Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9186-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 17:05:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17051 invoked by alias); 17 Aug 1999 17:05:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16976 invoked from network); 17 Aug 1999 17:05:49 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 17 Aug 1999 17:05:49 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id NAA04835; Tue, 17 Aug 1999 13:05:40 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id NAA11658; Tue, 17 Aug 1999 13:05:38 -0400 (EDT) Date: Tue, 17 Aug 1999 13:05:38 -0400 (EDT) From: John Wehle Message-Id: <199908171705.NAA11658@jwlab.FEITH.COM> To: roderik@ripe.net Subject: Re: built gcc 2.95 on i386-pc-bsdi3.1 Cc: gcc@gcc.gnu.org, bug-gcc@gnu.org, law@cygnus.com Content-Type: text > So if `filds' is an illegal instruction, is gcc 2.95's `configure' > script wrong in defining HAVE_GAS_FILDS_FISTS? I'm >90% sure I've seen > it defining that... `filds' isn't an illegal instruction, however it is spelled differently depending on what assembler you are using. Most assemblers seem to spell it `fild', some old versions of gas spell it `filds'. The problem you've encountered can happen if configure finds a different assembler from what is used at run time. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-9187-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 17:30:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24156 invoked by alias); 17 Aug 1999 17:30:14 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24105 invoked from network); 17 Aug 1999 17:30:10 -0000 Received: from birch.ripe.net (193.0.1.96) by egcs.cygnus.com with SMTP; 17 Aug 1999 17:30:10 -0000 Received: from ripe.net (x48.ripe.net [193.0.1.48]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id TAA17430; Tue, 17 Aug 1999 19:29:31 +0200 (CEST) Message-Id: <199908171729.TAA17430@birch.ripe.net> To: law@cygnus.com, John Wehle cc: gcc@gcc.gnu.org, bug-gcc@gnu.org Subject: Re: built gcc 2.95 on i386-pc-bsdi3.1 In-reply-to: Your message of Tue, 17 Aug 1999 13:05:38 EDT. <199908171705.NAA11658@jwlab.FEITH.COM> References: <199908171705.NAA11658@jwlab.FEITH.COM> From: Roderik Muit X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Tue, 17 Aug 1999 19:28:27 +0200 John Wehle writes: * `filds' isn't an illegal instruction, however it is spelled differently * depending on what assembler you are using. Most assemblers seem to * spell it `fild', some old versions of gas spell it `filds'. The problem * you've encountered can happen if configure finds a different assembler * from what is used at run time. Thanks for your answers. I'm sorry, I should have written back earlier. I found that the problem indeed was that configure was finding the BSDI 3.1 standard 'as', instead of the GNU binutils' 'as' which is installed somewhere else. When I specified DEFAULT_ASSEMBLER to configure, things worked and I experienced no problems in building gcc 2.95. (I didn't write back so far, since I would have liked to actually compile & test something before doing that. But I just can't find the time at the moment. You can assume everything is OK and add 'i386-pc-bsdi3.1' to the Build Status page on the Web.) Thanks, Roderik. From gcc-return-9188-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 19:25:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8238 invoked by alias); 17 Aug 1999 19:25:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8198 invoked from network); 17 Aug 1999 19:25:12 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 17 Aug 1999 19:25:12 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id VAA06612; Tue, 17 Aug 1999 21:25:06 +0200 (MET DST) Date: Tue, 17 Aug 1999 21:25:05 +0200 (MET DST) From: Gerald Pfeifer To: Jason Pond cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: Installing gcc 2.95 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 17 Aug 1999, Jason Pond wrote: > Does anyone have any ideas, or a more detailed installation procedure. Indeed we have received a couple of questions concerning that, so here is a patch which I' just applying to our documentation: Would that have helped you when installing GCC? Gerald Index: specific.html =================================================================== RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/install/specific.html,v retrieving revision 1.41 diff -r1.41 specific.html 24a25 >
  • *-*-solaris*
    • 425a427,435 >

    *-*-solaris*

    > >

    Starting with Solaris, Sun does not ship a C compiler any more. To > bootstrap and install GCC you first have to install a pre-built > compiler, for example from > http://www.sunfreeware.com.

    > > >
    439,443c449,455 <

    A bug in the SunOS4 linker will cause it to crash when linking -fPIC compiled < objects (and will therefore not allow you to build shared libraries).

    < <

    To fix this problem you can either use the most recent version of binutils or < get the latest SunOS4 linker patch (patch ID 100170-10) from Sun's patch site.

    --- >

    A bug in the SunOS4 linker will cause it to crash when linking > -fPIC compiled objects (and will therefore not allow you to build > shared libraries).

    > >

    To fix this problem you can either use the most recent version of > binutils or get the latest SunOS4 linker patch (patch ID 100170-10) > from Sun's patch site.

    479c491 <

    Last modified on August 15, 1999.

    --- >

    Last modified on August 17, 1999.

    From gcc-return-9189-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 19:35:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10738 invoked by alias); 17 Aug 1999 19:35:30 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10720 invoked from network); 17 Aug 1999 19:35:28 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 17 Aug 1999 19:35:28 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA01307; Tue, 17 Aug 1999 12:35:16 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id MAA21078; Tue, 17 Aug 1999 12:35:16 -0700 (PDT) Date: Tue, 17 Aug 1999 12:35:16 -0700 (PDT) Message-Id: <199908171935.MAA21078@kankakee.wrs.com> To: mark@codesourcery.com, zack@bitmover.com Subject: Re: Recursion Optimization Cc: gcc@gcc.gnu.org, kevinatk@home.com > From: Mark Mitchell > Date: Mon, 16 Aug 1999 23:19:32 -0700 > Not directly. But, in the long term, it is my opinion that the C > front-end and the C++ front-end should merge, or at least share a > tremendous amount of common code. :-) Well, more of the later than the former. I don't think the first is realistic. The second one can do by identifying common things and moving the code out to a common area, full documenting it and describing the semantics of it, and changing the frontends to use it. I see no reason why extremely large swaths of code can't be shared. Unfortunately, there isn't enough attention payed to high level common semantics I think to allow for this type of unification. This happens at lower levels fairly well (rtl and down), but trees and up, it seems like more could be done. Let me give one simple example. The symbol table. The one in C++ is powerful, have tons of interesting semantics, is probably a proper super set of most other langauges, and yet, there is almost zero sharing (I think the hash function is shared). This includes peripheral routines like symbol lookup. I think in time, we need to migrate more routines from frontends (now that we actually have more than 2 of them :-)) to the midend, and in so doing collapse and unify them. I think we should do it lazily and only when two or more frontends actually need the semantics. If someone wanted to try their hand at it, we could vote and nominate a bit of functionality, and the person could try it out. I don't think it would be that hard, just have to pay attention to detail and be able to unify to seemingly disparate sets of code. Though, I imagine the interfaces would also need to be cleansed of impurities (hey, I am sure we have some of those in C++) and various code jiggered with so that it would fit. From gcc-return-9190-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 20:07:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14720 invoked by alias); 17 Aug 1999 20:07:31 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14704 invoked from network); 17 Aug 1999 20:07:23 -0000 Received: from custos.foa.se (HELO mercur.foa.se) (150.227.16.253) by egcs.cygnus.com with SMTP; 17 Aug 1999 20:07:23 -0000 Received: from hobbe.lin.foa.se (hobbe.lin.foa.se [150.227.33.76]) by mercur.foa.se (8.9.3/8.9.3) with SMTP id WAA14871 for ; Tue, 17 Aug 1999 22:07:20 +0200 (MET DST) Received: from arnljot.lin.foa.se by hobbe.lin.foa.se (SMI-8.6/SMI-SVR4) id WAA12421; Tue, 17 Aug 1999 22:06:45 +0200 Received: from arnljot.lin.foa.se (IDENT:chj@localhost [127.0.0.1]) by arnljot.lin.foa.se (8.9.3/8.9.3) with ESMTP id WAA27264 for ; Tue, 17 Aug 1999 22:09:20 +0200 Message-Id: <199908172009.WAA27264@arnljot.lin.foa.se> X-Mailer: exmh version 2.0.2 To: gcc@gcc.gnu.org Subject: Testsuites and releases of gcc From: Christian =?iso-8859-1?Q?J=F6nsson?= FOA 72 X-face: 2tQjSw>|IA680lA7r'G9Y[jfoS>tTPw4-B#mQo_C+{6>^DWZP`o.h Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16082 invoked by alias); 17 Aug 1999 22:33:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16067 invoked from network); 17 Aug 1999 22:33:55 -0000 Received: from linuxpc1.lauterbach.com (qmailr@194.195.165.177) by egcs.cygnus.com with SMTP; 17 Aug 1999 22:33:55 -0000 Received: (qmail 26932 invoked from network); 17 Aug 1999 22:33:51 -0000 Received: from ns2006.munich.netsurf.de (HELO ns1102.munich.netsurf.de) (195.180.232.6) by linuxpc1 with SMTP; 17 Aug 1999 22:33:51 -0000 From: Franz Sirl To: Joern Rennecke Subject: Re: Deadly optimization bug (all gcc versions!) Date: Wed, 18 Aug 1999 00:24:21 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com References: <199908162254.XAA02643@phal.cygnus.co.uk> <99081701395000.00901@ns1102.munich.netsurf.de> In-Reply-To: <99081701395000.00901@ns1102.munich.netsurf.de> MIME-Version: 1.0 Message-Id: <99081800342400.02624@ns1102.munich.netsurf.de> Content-Transfer-Encoding: 8bit Am Die, 17 Aug 1999 schrieb Franz Sirl: >So the feed rules are fulfilled. In the meantime I believe I narrowed it down a >bit to this code around line 1740: > > /* If we already got a failure, don't try to do more. Otherwise, > try to substitute in I1 if we have it. */ > > if (i1 && GET_CODE (newpat) != CLOBBER) > { > /* Before we can do this substitution, we must redo the test done > above (see detailed comments there) that ensures that I1DEST > isn't mentioned in any SETs in NEWPAT that are field assignments. */ > > if (! combinable_i3pat (NULL_RTX, &newpat, i1dest, NULL_RTX, > 0, NULL_PTR)) > { > undo_all (); > return 0; > } > > n_occurrences = 0; > subst_low_cuid = INSN_CUID (i1); > newpat = subst (newpat, i1dest, i1src, 0, 0); > undobuf.previous_undos = undobuf.undos; > } > > >Before the call to subst newpat/i1dest/i1src look like: > >(gdb) p debug_rtx(newpat) > >(set (reg:SI 86) > (plus:SI (lshiftrt:SI (reg/v:SI 84) > (const_int 1 [0x1])) > (reg/v:SI 85))) >$184 = void >(gdb) p debug_rtx(i1dest) > >(reg/v:SI 85) >$185 = void >(gdb) p debug_rtx(i1src) > >(lshiftrt:SI (reg:SI 3 r3) > (const_int 1 [0x1])) > >which looks quite reasonable for newpat (I'm not sure about i1dest/i1src). >But after subst() newpat looks like: > >(gdb) p debug_rtx(newpat) > >(set (reg:SI 86) > (lshiftrt:SI (reg:SI 3 r3) > (const_int 1 [0x1]))) In subst() this code after the else around line 3200 is entered: else /* If we are in a SET_DEST, suppress most cases unless we have gone inside a MEM, in which case we want to simplify the address. We assume here that things that are actually part of the destination have their inner parts in the first expression. This is true for SUBREG, STRICT_LOW_PART, and ZERO_EXTRACT, which are the only things aside from REG and MEM that should appear in a SET_DEST. */ new = subst (XEXP (x, i), from, to, (((in_dest && (code == SUBREG || code == STRICT_LOW_PART || code == ZERO_EXTRACT)) || code == SET) && i == 0), unique_copy); /* If we found that we will have to reject this combination, indicate that by returning the CLOBBER ourselves, rather than an expression containing it. This will speed things up as well as prevent accidents where two CLOBBERs are considered to be equal, thus producing an incorrect simplification. */ if (GET_CODE (new) == CLOBBER && XEXP (new, 0) == const0_rtx) return new; SUBST (XEXP (x, i), new); At the SUBST x, new and i look like: Breakpoint 4, subst (x=0x1af5560, from=0x1af5448, to=0x1af5470, in_dest=0, unique_copy=0) at ../../../cvsx/gccm/gcc/combine.c:3200 3200 SUBST (XEXP (x, i), new); (gdb) p debug_rtx(x) (set (reg:SI 86) (plus:SI (lshiftrt:SI (reg/v:SI 84) (const_int 1 [0x1])) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1])))) $70 = void (gdb) p debug_rtx(new) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1])) $71 = void (gdb) p i $72 = 1 If I step over this we get the faulty rtx: (gdb) n 3115 for (i = 0; i < len; i++) (gdb) p debug_rtx(x) (set (reg:SI 86) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1]))) $82 = void I believe that in this case something like XVECEXP(x,i,1) is needed in the SUBST() instead of the XEXP(x,i). But I have no idea what to check for a correct decision :-). Franz. From gcc-return-9192-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 22:42:12 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18597 invoked by alias); 17 Aug 1999 22:42:11 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18571 invoked from network); 17 Aug 1999 22:42:09 -0000 Received: from keg.math.ualberta.ca (root@129.128.88.242) by egcs.cygnus.com with SMTP; 17 Aug 1999 22:42:09 -0000 Received: (from hubert@localhost) by keg.math.ualberta.ca (8.8.7/8.8.7) id QAA24541; Tue, 17 Aug 1999 16:41:00 -0600 To: gcc@gcc.gnu.org Subject: successful gcc build X-Url-From: http://www.gnu.org/software/gcc/install/finalinstall.html X-Mailer: Emacs-W3/4.0pre.44 From: Hubert Chan Date: 17 Aug 1999 16:41:00 -0600 Message-ID: Lines: 2 I built gcc 2.95 successfully. Output from config.guess is "alphaev6-unknown-linux-gnu". From gcc-return-9193-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 22:47:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20312 invoked by alias); 17 Aug 1999 22:47:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20264 invoked from network); 17 Aug 1999 22:47:08 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 17 Aug 1999 22:47:08 -0000 Received: (qmail 753 invoked by alias); 17 Aug 1999 22:47:04 -0000 Received: (qmail 735 invoked from network); 17 Aug 1999 22:47:01 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 17 Aug 1999 22:47:01 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id XAA13829; Tue, 17 Aug 1999 23:46:29 +0100 From: Joern Rennecke Message-Id: <199908172246.XAA13829@phal.cygnus.co.uk> Subject: Re: Deadly optimization bug (all gcc versions!) In-Reply-To: <99081800342400.02624@ns1102.munich.netsurf.de> from Franz Sirl at "Aug 18, 1999 0:24:21 am" To: Franz.Sirl-kernel@lauterbach.com (Franz Sirl) Date: Tue, 17 Aug 1999 23:46:29 +0100 (BST) Cc: amylaar@cygnus.co.uk, dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I believe that in this case something like XVECEXP(x,i,1) is needed in the > SUBST() instead of the XEXP(x,i). But I have no idea what to check for a No. The objective of this piece of code is to process XEXP(x, i) . The problem is that an incorrect value for new has been calculated. Find out why. From gcc-return-9194-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 23:24:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28431 invoked by alias); 17 Aug 1999 23:24:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28412 invoked from network); 17 Aug 1999 23:24:26 -0000 Received: from mercury.sun.com (192.9.25.1) by egcs.cygnus.com with SMTP; 17 Aug 1999 23:24:26 -0000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA13565 for ; Tue, 17 Aug 1999 16:24:24 -0700 (PDT) Received: from mamacita.Eng.Sun.COM (mamacita.Eng.Sun.COM [129.144.178.1]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id QAA21234 for ; Tue, 17 Aug 1999 16:24:24 -0700 (PDT) Received: from loisel by mamacita.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id QAA00779; Tue, 17 Aug 1999 16:24:23 -0700 Date: Tue, 17 Aug 1999 16:24:23 -0700 (PDT) From: Sebastien Loisel Reply-To: Sebastien Loisel Subject: Bounds Checking To: gcc@gcc.gnu.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kV4e986BcaHxZHV4huzQ2g== X-Mailer: dtmail 1.1.0 CDE Version 1.1.1 SunOS 5.5.1 sun4u sparc Hello. I noticed a one month old thread about bounds checking for gcc. This would be very useful to many of us. The thread mostly discussed fat pointers and some other hacks which were less clear to me. I would like to point out that Richard Jones and Paul Kelly a long time ago (1995) released patches for gcc 2.7.0 (and then to 2.7.1 and 2.7.2) for fine grained bounds checking. According to the web page, the method they use preserves binary compatibility and does not result in ridiculous slowdowns. If anyone is going to implement this (and I certainly hope it will happen), it seems that Richard and Paul's work should be checked out. However, I have never tried it myself so I can't really answer any questions. http://www-ala.doc.ic.ac.uk/~phjk/BoundsChecking.html Sebastien Loisel -- McGill University -- Sun Microsystems http://www.math.mcgill.ca/~loisel/ From gcc-return-9195-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 17 23:28:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31300 invoked by alias); 17 Aug 1999 23:28:40 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31257 invoked from network); 17 Aug 1999 23:28:35 -0000 Received: from linuxpc1.lauterbach.com (qmailr@194.195.165.177) by egcs.cygnus.com with SMTP; 17 Aug 1999 23:28:35 -0000 Received: (qmail 27602 invoked from network); 17 Aug 1999 23:28:31 -0000 Received: from ns2006.munich.netsurf.de (HELO ns1102.munich.netsurf.de) (195.180.232.6) by linuxpc1 with SMTP; 17 Aug 1999 23:28:31 -0000 From: Franz Sirl To: Joern Rennecke Subject: Re: Deadly optimization bug (all gcc versions!) Date: Wed, 18 Aug 1999 01:25:23 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com References: <199908172246.XAA13829@phal.cygnus.co.uk> In-Reply-To: <199908172246.XAA13829@phal.cygnus.co.uk> MIME-Version: 1.0 Message-Id: <99081801291800.04108@ns1102.munich.netsurf.de> Content-Transfer-Encoding: 8bit Am Mit, 18 Aug 1999 schrieb Joern Rennecke: >> I believe that in this case something like XVECEXP(x,i,1) is needed in the >> SUBST() instead of the XEXP(x,i). But I have no idea what to check for a > >No. The objective of this piece of code is to process XEXP(x, i) . >The problem is that an incorrect value for new has been calculated. >Find out why. Hmm, I assume because simplify_rtx does the following: 3200 SUBST (XEXP (x, i), new); (gdb) 3115 for (i = 0; i < len; i++) (gdb) p debug_rtx(x) (plus:SI (lshiftrt:SI (reg/v:SI 84) (const_int 1 [0x1])) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1]))) $21 = void (gdb) p len $22 = 2 (gdb) n 3209 for (i = 0; i < 4; i++) (gdb) 3213 if (code != CONST_INT && code != REG && code != CLOBBER) (gdb) 3214 x = simplify_rtx (x, op0_mode, i == 3, in_dest); (gdb) 3216 if (GET_CODE (x) == code) (gdb) p debug_rtx(x) (if_then_else:SI (ne (reg/v:SI 84) (const_int 0 [0x0])) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1])) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1]))) $23 = void This IF_THEN_ELSE doesn't look right to me. I'll continue debugging tomorrow, it's already too late here :-). Thanks for your assistance, Franz. From gcc-return-9196-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 05:24:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13949 invoked by alias); 18 Aug 1999 05:24:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13934 invoked from network); 18 Aug 1999 05:24:20 -0000 Received: from dhcp-sv-18.cygnus.com (HELO upchuck.cygnus.com) (205.180.231.98) by egcs.cygnus.com with SMTP; 18 Aug 1999 05:24:20 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id XAA04849; Tue, 17 Aug 1999 23:21:25 -0600 To: "Jason Pond" cc: gcc@gcc.gnu.org Subject: Re: Installing gcc 2.95 Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 17 Aug 1999 12:00:18 -0230. Date: Tue, 17 Aug 1999 23:21:24 -0600 Message-ID: <4846.934953684@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > I posted this message earlier but i still haven't been successful in instal > ling GCC-2.95. I am sending it again with hopes that someone may be able t > o help me out. > Configuring for a sparc-sun-solaris2.6 host. > Created "Makefile" in /usr1/gcc using "mh-frag" > /usr/ucb/cc: language optional software package not installed > *** The command '/usr/ucb/cc -o conftest -g conftest.c' failed. > *** You must set the environment variable CC to a working compiler. You do not have a C compiler on your system. You must have a C compiler to build GCC. jeff From gcc-return-9197-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 07:05:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26679 invoked by alias); 18 Aug 1999 07:05:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26592 invoked from network); 18 Aug 1999 07:05:48 -0000 Received: from mserv.rug.ac.be (157.193.40.37) by egcs.cygnus.com with SMTP; 18 Aug 1999 07:05:48 -0000 Received: from intec.intec.rug.ac.be (intec.rug.ac.be [157.193.92.67]) by mserv.rug.ac.be (8.9.0/8.9.0) with SMTP id JAA02575 for ; Wed, 18 Aug 1999 09:05:45 +0200 (MET DST) Received: from pcdesign9.intec.rug.ac.be by intec.intec.rug.ac.be with SMTP (1.38.193.4/16.2) id AA14055; Wed, 18 Aug 1999 09:04:17 +0200 Message-Id: <3.0.32.19990818090018.009658a0@mailserver.intec.rug.ac.be> X-Sender: tsys@mailserver.intec.rug.ac.be X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 18 Aug 1999 09:00:19 +0200 To: gcc@gcc.gnu.org From: Tom Sys Subject: i960-VH Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" We are looking for the GCC-compiler for the i960 VH. We see however that this CPU-type is not yet supported as the choices for '-mcpu' are `ka', `kb', `mc', `ca', `cf', `sa', and `sb'. Has anyone already started to add this type or can anyone give us more information on this topic. Any help would be very much appreciated, Tom Sys tsys@intec.rug.ac.be From gcc-return-9198-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 10:05:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22432 invoked by alias); 18 Aug 1999 10:05:12 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22415 invoked from network); 18 Aug 1999 10:05:10 -0000 Received: from sonne.darmstadt.gmd.de (141.12.62.20) by egcs.cygnus.com with SMTP; 18 Aug 1999 10:05:10 -0000 Received: from pc-topaz.darmstadt.gmd.de (pc-topaz [141.12.32.46]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id MAA05122; Wed, 18 Aug 1999 12:05:02 +0200 (MET DST) Received: from darmstadt.gmd.de (localhost [127.0.0.1]) by pc-topaz.darmstadt.gmd.de (8.9.3/8.8.7) with ESMTP id MAA04767; Wed, 18 Aug 1999 12:07:28 +0200 Message-ID: <37BA85DF.8EEAB34A@darmstadt.gmd.de> Date: Wed, 18 Aug 1999 12:07:27 +0200 From: Joerg Pommnitz Organization: GMD X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: de-DE MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Possible bug in g++: 0U == 0 == NULL? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following small test case fails to compile with gcc-2.95: ----------------------------------- void foo (void *p) { } void foo (unsigned short s) { } int main () { foo (0U); } ----------------------------------- The compiler complains that test.cc: In function `int main()': test.cc:12: call of overloaded `foo (unsigned int)' is ambiguous test.cc:2: candidates are: void foo(void *) test.cc:6: void foo(short unsigned int) Note that the argument is 0U and those marked not to be a pointer... g++ is Reading specs from /usr/lib/gcc-lib/i386-linux/2.95/specs gcc version 2.95 19990728 (release) -- Regards Joerg GMD-IPSI, Dolivostr. 15, Zimmer 120, D-64293 Darmstadt +49-6151-869-786 (Phone), -818 (FAX) From gcc-return-9199-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 10:18:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24724 invoked by alias); 18 Aug 1999 10:17:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24704 invoked from network); 18 Aug 1999 10:17:27 -0000 Received: from guardian.hermes.si (193.77.5.150) by egcs.cygnus.com with SMTP; 18 Aug 1999 10:17:27 -0000 Received: from hermes.si (primus.hermes.si [193.77.5.98]) by guardian.hermes.si (8.9.3/8.9.3) with ESMTP id MAA26078; Wed, 18 Aug 1999 12:16:32 +0200 (METDST) Received: from lux.hermes.si (lux.hermes.si [10.17.4.137]) by hermes.si (8.9.3/8.9.3) with SMTP id MAA14732; Wed, 18 Aug 1999 12:16:27 +0200 (METDST) Received: from hermes.si by lux.hermes.si (SMI-8.6/SMI-SVR4) id MAA06494; Wed, 18 Aug 1999 12:16:26 +0200 Message-ID: <37BA8802.E1631331@hermes.si> Date: Wed, 18 Aug 1999 12:16:34 +0200 From: Branko Cibej Organization: HERMES SoftLab X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: sl,en-GB,en MIME-Version: 1.0 To: Joerg Pommnitz CC: gcc@gcc.gnu.org Subject: Re: Possible bug in g++: 0U == 0 == NULL? References: <37BA85DF.8EEAB34A@darmstadt.gmd.de> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Joerg Pommnitz wrote: > The following small test case fails to compile with > gcc-2.95: [snip] > The compiler complains that > test.cc: In function `int main()': > test.cc:12: call of overloaded `foo (unsigned int)' is ambiguous > test.cc:2: candidates are: void foo(void *) > test.cc:6: void foo(short unsigned int) > > Note that the argument is 0U and those marked not > to be a pointer... It is written: 4.10 Pointer Conversions [conv.ptr] 1 A _null pointer constant_ is an integral constant expression (5.19) rvalue of integer type that evaluates to zero. A null pointer constant can be converted to a pointer type; the result is a _null pointer value_ of that type ... GCC is right. BTW, that's an *old* C++ FAQ. Brane -- Branko Èibej HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia voice: (+386 61) 186 53 49 fax: (+386 61) 186 52 70 From gcc-return-9200-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 11:03:23 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30514 invoked by alias); 18 Aug 1999 11:03:21 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30496 invoked from network); 18 Aug 1999 11:03:18 -0000 Received: from irafs1.ira.uka.de (@129.13.10.100) by egcs.cygnus.com with SMTP; 18 Aug 1999 11:03:18 -0000 Received: from satyr [129.13.216.40] (actually isdn216-40.rz.uni-karlsruhe.de) by irafs1 with SMTP (PP); Wed, 18 Aug 1999 13:02:49 +0200 Received: by satyr.de (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 18 Aug 99 13:01:54 Received: by satyr.de (Amiga SMTPpost 1.04 December 9, 1994) id AA01; Wed, 18 Aug 99 11:53:14 From: s_fuhrm@ira.uka.de (Stephan Fuhrmann) Message-Id: <28ae5fa4.u9t27e.2acae-fury@satyr.de> Subject: external template instantiation example?! Reply-To: Stephan.Fuhrmann@stud.uni-karlsruhe.de X-Mailer: //\\miga Electronic Mail (AmiElm 9.27) Date: Wed, 18 Aug 99 11:53:14 To: gcc@gcc.gnu.org Hi there!! I'm having a problem instantiating some template classes from other code. Here's the example code: ********** myclass.h: interface for 'class myclass', no functions here template class myclass { public: T a; add(T b); } myclass.cpp: implementation of 'class myclass' #include "myclass.h" template myclass::add(T b) { a+=b; } myprog.cpp: program using 'class myclass', including 'myclass.h' #include "myclass.h" int main(int argc,char *argv[]) { myclass i; myclass c; c.add(2); i.add(1); i.add(c.a); return 0; } *********** Here's my question: how can I use 'class myclass' in 'myprog.cpp' without instantiating the needed templates before manually? Can you come up with an example? If I have to instantiate manually, how can I do it with small effort (i.e. tell the compiler to generate all methods of the class)? Best wishes Stephan From gcc-return-9201-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 12:16:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14176 invoked by alias); 18 Aug 1999 12:16:05 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13657 invoked from network); 18 Aug 1999 12:15:57 -0000 Received: from relais1.steria.fr (193.104.139.252) by egcs.cygnus.com with SMTP; 18 Aug 1999 12:15:57 -0000 Received: from mail.aix.net.steria.fr ([168.0.80.246]) by relais1.steria.fr (Netscape Messaging Server 3.62) with ESMTP id 302 for ; Wed, 18 Aug 1999 14:19:13 +0200 Received: from steria.fr ([168.0.80.27]) by mail.aix.net.steria.fr (Netscape Messaging Server 3.52) with ESMTP id 2048 for ; Wed, 18 Aug 1999 14:20:17 +0200 Message-ID: <37BAA444.CAC2868@steria.fr> Date: Wed, 18 Aug 1999 14:17:08 +0200 From: =?iso-8859-1?Q?Jean=2DFran=E7ois?= MORCILLO Organization: Atelier B X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: warning with gcc 2.95.1 References: <934969944.21603.ezmlm@gcc.gnu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit with gcc 2.95.1 I receive the folowing warning : 'void *' is not a pointer-to-object type but I newer had this warnibg with previous gcc or egcs version !!!! can someone help me From gcc-return-9202-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 12:23:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21817 invoked by alias); 18 Aug 1999 12:23:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21781 invoked from network); 18 Aug 1999 12:23:26 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 18 Aug 1999 12:23:26 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id FAA29443; Wed, 18 Aug 1999 05:22:55 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id FAA17543; Wed, 18 Aug 1999 05:22:50 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id FAA23677; Wed, 18 Aug 1999 05:22:49 -0700 Message-Id: <199908181222.FAA23677@atrus.synopsys.com> Subject: Re: warning with gcc 2.95.1 To: Jean-Francois.Morcillo@steria.fr (=?iso-8859-1?Q?Jean=2DFran=E7ois?= MORCILLO) Date: Wed, 18 Aug 99 5:22:49 PDT Cc: gcc@gcc.gnu.org In-Reply-To: <37BAA444.CAC2868@steria.fr>; from "=?iso-8859-1?Q?Jean=2DFran=E7ois?= MORCILLO" at Aug 18, 99 2:17 pm X-Mailer: ELM [version 2.3 PL11] > with gcc 2.95.1 I receive the folowing warning : 'void *' is not a pointer-to-object type > but I newer had this warnibg with previous gcc or egcs version !!!! We'd need to see the code in question. Either you are using some invalid C++ that previous compilers accepted by mistake, or there is a new bug, but I suspect the former. From gcc-return-9203-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 12:36:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23896 invoked by alias); 18 Aug 1999 12:36:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23860 invoked from network); 18 Aug 1999 12:36:42 -0000 Received: from relais1.steria.fr (193.104.139.252) by egcs.cygnus.com with SMTP; 18 Aug 1999 12:36:41 -0000 Received: from mail.aix.net.steria.fr ([168.0.80.246]) by relais1.steria.fr (Netscape Messaging Server 3.62) with ESMTP id 260 for ; Wed, 18 Aug 1999 14:39:57 +0200 Received: from steria.fr ([168.0.80.27]) by mail.aix.net.steria.fr (Netscape Messaging Server 3.52) with ESMTP id 2046; Wed, 18 Aug 1999 14:40:44 +0200 Message-ID: <37BAA90F.3A4573D9@steria.fr> Date: Wed, 18 Aug 1999 14:37:35 +0200 From: =?iso-8859-1?Q?Jean=2DFran=E7ois?= MORCILLO Organization: Atelier B X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Joe Buck CC: gcc@gcc.gnu.org Subject: Re: warning with gcc 2.95.1 References: <199908181222.FAA23677@atrus.synopsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joe Buck wrote: > > with gcc 2.95.1 I receive the folowing warning : 'void *' is not a pointer-to-object type > > but I newer had this warnibg with previous gcc or egcs version !!!! > > We'd need to see the code in question. Either you are using some invalid > C++ that previous compilers accepted by mistake, or there is a new bug, > but I suspect the former. the code look like this : void my_delete(void *adr) { //some stuff ... //free memory delete adr ; } in the C++ Programming Lanhuage Third edition, le the prototype for operator delete is the same.... From gcc-return-9204-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 12:37:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24129 invoked by alias); 18 Aug 1999 12:37:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23732 invoked from network); 18 Aug 1999 12:35:23 -0000 Received: from rumcajs.chemie.uni-halle.de (rysio@141.48.254.65) by egcs.cygnus.com with SMTP; 18 Aug 1999 12:35:23 -0000 Received: from localhost (rysio@localhost) by rumcajs.chemie.uni-halle.de (8.9.0/8.8.8) with SMTP id OAA22333 for ; Wed, 18 Aug 1999 14:34:19 +0200 Date: Wed, 18 Aug 1999 14:34:19 +0200 (CEST) From: Ryszard Kabatek Reply-To: Ryszard Kabatek To: gcc@gcc.gnu.org Subject: gcc-2.95 and -fhonor-std Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I get a linker error if I try to use the -fhonor-std option. I compiled the compiler with the standard options. I get the error on Linux libc5 and glibc2 systems. Sould I compile the compiler with a special option? BTW. If I include the header with gcc-2.95.1 (Linux, libc5) I get a lot of warnings. // x.cc #include int main(){std::exception e;} eg++ -fhonor-std x.cc /tmp/cc1H7VkX.o: In function `main': /tmp/cc1H7VkX.o(.text+0xe): undefined reference to `std::exception::exception(void)' /tmp/cc1H7VkX.o(.text+0x2a): undefined reference to `std::exception::~exception(void)' /tmp/cc1H7VkX.o(.text+0x41): undefined reference to `std::exception::~exception(void)' /tmp/cc1H7VkX.o(.text+0x56): undefined reference to `std::terminate(void)' collect2: ld returned 1 exit status Ryszard Kabatek Martin-Luther University Halle-Wittenberg, Department of Physical Chemistry Geusaer Str. 88, 06217 Merseburg, Germany Tel. +49 3461 46 2466 Fax. +49 3461 46 2129 From gcc-return-9205-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 13:04:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6713 invoked by alias); 18 Aug 1999 13:04:07 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6697 invoked from network); 18 Aug 1999 13:04:06 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 18 Aug 1999 13:04:06 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA27417; Wed, 18 Aug 1999 06:04:04 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id GAA22137; Wed, 18 Aug 1999 06:04:04 -0700 (PDT) Date: Wed, 18 Aug 1999 06:04:04 -0700 (PDT) Message-Id: <199908181304.GAA22137@kankakee.wrs.com> To: Jean-Francois.Morcillo@steria.fr, jbuck@synopsys.COM Subject: Re: warning with gcc 2.95.1 Cc: gcc@gcc.gnu.org > Date: Wed, 18 Aug 1999 14:37:35 +0200 > From: =?iso-8859-1?Q?Jean=2DFran=E7ois?= MORCILLO > > the code look like this : > void my_delete(void *adr) > { > //some stuff > ... > //free memory > delete adr ; > } > in the C++ Programming Lanhuage Third edition, le the prototype for > operator delete is the same.... Wrong type, please ask how to a program in C++ type questions on comp.lang.c++. Try delete new char; or _any_ other type but void, above you use void. delete new void; is invalid. From gcc-return-9206-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 13:11:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7905 invoked by alias); 18 Aug 1999 13:11:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7888 invoked from network); 18 Aug 1999 13:11:08 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 18 Aug 1999 13:11:08 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA27883; Wed, 18 Aug 1999 06:10:53 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id GAA22146; Wed, 18 Aug 1999 06:10:53 -0700 (PDT) Date: Wed, 18 Aug 1999 06:10:53 -0700 (PDT) Message-Id: <199908181310.GAA22146@kankakee.wrs.com> To: gcc@gcc.gnu.org, tsys@intec.rug.ac.be Subject: Re: i960-VH > Date: Wed, 18 Aug 1999 09:00:19 +0200 > From: Tom Sys > We are looking for the GCC-compiler for the i960 VH. We see however > that this CPU-type is not yet supported as the choices for '-mcpu' > are `ka', `kb', `mc', `ca', `cf', `sa', and `sb'. Has anyone > already started to add this type or can anyone give us more > information on this topic. It is often the case that new chips are backwards compatible with a previous chip. It it often the case the the semiconductor vendor doesn't add support for all their chips to the compiler. Complain to your semiconductor vendor. You should be able to identify what chip it is backwards compatible with and use that on the gcc command line. If you want, you can then add the information to gcc/config/i960/i960.[hc] and help us. As you can see, we can use all the help you can spare. :-) From gcc-return-9207-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 13:14:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8847 invoked by alias); 18 Aug 1999 13:14:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8828 invoked from network); 18 Aug 1999 13:14:22 -0000 Received: from dire.bris.ac.uk (137.222.10.60) by egcs.cygnus.com with SMTP; 18 Aug 1999 13:14:22 -0000 Received: from cs.bris.ac.uk (actually host luna.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 18 Aug 1999 14:14:05 +0100 Received: from acm.org (manao [137.222.102.67]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id OAA05283; Wed, 18 Aug 1999 14:10:12 +0100 (BST) Message-ID: <37BAB0B3.9A627228@acm.org> Date: Wed, 18 Aug 1999 14:10:11 +0100 From: Nathan Sidwell Reply-To: nathan@compsci.bristol.ac.uk Organization: University of Bristol X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?Jean=2DFran=E7ois?= MORCILLO CC: Joe Buck , gcc@gcc.gnu.org Subject: Re: warning with gcc 2.95.1 References: <199908181222.FAA23677@atrus.synopsys.com> <37BAA90F.3A4573D9@steria.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Jean-Frangois MORCILLO wrote: > the code look like this : > void my_delete(void *adr) > { > //some stuff > ... > //free memory > delete adr ; > } > > in the C++ Programming Lanhuage Third edition, le the prototype for operator delete is the > same.... [expr.delete] 5.3.5/2 '... the pointer shall be a pointer to a non-array object ...' void * is not a pointer to object. Your code is incorrect. You might mean operator delete (adr); which _is_ different. nathan -- Dr Nathan Sidwell :: Computer Science Department :: Bristol University I have seen the death of PhotoShop -- it is called GIMP nathan@acm.org http://www.cs.bris.ac.uk/~nathan/ nathan@cs.bris.ac.uk From gcc-return-9208-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 13:33:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11164 invoked by alias); 18 Aug 1999 13:33:35 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11148 invoked from network); 18 Aug 1999 13:33:31 -0000 Received: from ariane.ens-cachan.fr (138.231.176.4) by egcs.cygnus.com with SMTP; 18 Aug 1999 13:33:31 -0000 Received: from mayo.cmla.ens-cachan.fr (mayo.cmla.ens-cachan.fr [138.231.64.2]) by ariane.ens-cachan.fr (8.8.8/jtpda-5.3.1) with ESMTP id PAA00311 ; Wed, 18 Aug 1999 15:33:18 +0200 (MET DST) Received: from poivre.cmla.ens-cachan.fr (poivre.cmla.ens-cachan.fr [138.231.64.15]) by mayo.cmla.ens-cachan.fr (8.9.3/jtpda-5.3.1/CL) with ESMTP id PAA15638 ; Wed, 18 Aug 1999 15:33:14 +0200 (MET DST) Received: from (dosreis@localhost) by poivre.cmla.ens-cachan.fr (8.9.3/jtpda-5.3.1/CL) id PAA28146 ; Wed, 18 Aug 1999 15:33:14 +0200 (MET DST) To: Peter Nilsson Cc: libstdc++@sourceware.com, egcs@egcs.cygnus.com Subject: Re: Thread safety libstdc++ Reply-To: libstdc++@sourceware.com, egcs@egcs.cygnus.com References: From: Gabriel Dos Reis In-Reply-To: Peter Nilsson's message of "Wed, 18 Aug 1999 15:03:18 +0200" Organization: CMLA, ENS Cachan -- CNRS URA 1611 (France) Date: 18 Aug 1999 15:33:13 +0200 Message-ID: Lines: 25 X-Mailer: Gnus v5.6.45/Emacs 19.34 Peter Nilsson writes: | Hi! | 1. Do you plan to implement thread safety in libstdc++ in the nearest future? If yes, about when? Yes it is one of our goal to make libstdc++ as MT safe as possible. Much effort has been spent in that direction in the v-3 project. The plan is to release gcc-3.0 with v-3, but that remains a plan. | 2. I'm using the libio distributed with gcc-2.95. In the file gcc-2.95/libio/README you can read: | | ... | This library is distributed with libg++; see ../libg++/README | for installation instructions... | ... | | But there is no directory ../libg++ included! Well, the libstdc++ that comes with gcc-2.95 needs badly consistency... | So, where then can I find information about how to install libio with/without thread-safety, what is default, etc. I've looked for it as a mainjack... Weel, I let Uli answer this one :-) -- Gaby From gcc-return-9209-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 13:42:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13460 invoked by alias); 18 Aug 1999 13:42:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13442 invoked from network); 18 Aug 1999 13:42:24 -0000 Received: from roma.axis.se (193.13.178.2) by egcs.cygnus.com with SMTP; 18 Aug 1999 13:42:24 -0000 Received: from klatt.axis.se (klatt.axis.se [193.13.178.103]) by roma.axis.se (8.9.3/8.9.3) with ESMTP id PAA09209; Wed, 18 Aug 1999 15:42:16 +0200 (MEST) Received: by klatt.axis.se with Internet Mail Service (5.5.2448.0) id ; Wed, 18 Aug 1999 15:39:14 +0200 Message-ID: From: Peter Nilsson To: "'libstdc++@sourceware.com'" , "'egcs@egcs.cygnus.com'" Subject: RE: Thread safety libstdc++ Date: Wed, 18 Aug 1999 15:39:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Thanks for your quick response. | Hi! | 1. Do you plan to implement thread safety in libstdc++ in the nearest future? If yes, about when? Yes it is one of our goal to make libstdc++ as MT safe as possible. Much effort has been spent in that direction in the v-3 project. The plan is to release gcc-3.0 with v-3, but that remains a plan. And when would that be? Do you know by know? /Peter From gcc-return-9210-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 13:52:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15201 invoked by alias); 18 Aug 1999 13:52:11 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15185 invoked from network); 18 Aug 1999 13:52:06 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 18 Aug 1999 13:52:06 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id PAA17466; Wed, 18 Aug 1999 15:51:53 +0200 (MET DST) Date: Wed, 18 Aug 1999 15:51:48 +0200 (MET DST) From: Gerald Pfeifer To: Matthias Klose cc: gcc@gcc.gnu.org, Jason Molenda Subject: Re: Index pages for mailing list archives In-Reply-To: <199908171653.SAA15176@bolero.cs.tu-berlin.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII [ I added a Cc: to Jason, our sysadmin who manages the mailing list archives. ] On Tue, 17 Aug 1999, Matthias Klose wrote: > From the index pages you can only reach the date index for each mailing > list. It would be nice to have something like > - August, 1999 [Date Index] [Subject Index] [Author Index] [Thread Index] > to go directly to each index. By index pages you mean http://egcs.cygnus.com/ml/gcc/, right? Hm, well, adding what you ask for might be useful. If it's easy, let's give it a try (but it's probably not worth too much effort just to save a single mouse-click). > An alternative would be to skip these pages altogether, and provide > a http://egcs.cygnus.com/lists.html which has direct pointers to the > mailing list archives (like http://www.debian.org/Lists-Archives). I'd prefer not to clutter lists.html any further, but clearly, if you have a good suggestion on how to improve that page, I'd be highly interested. (Patches welcome! ;-) ) > Where can I find the mhonarc templates and scripts for the generation > of the archives? I believe these are not yet publicly available. Jason, how about adding these to our CVS repository as wwwdocs/mhonarc? Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9211-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 13:55:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16238 invoked by alias); 18 Aug 1999 13:55: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16208 invoked from network); 18 Aug 1999 13:55:24 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 18 Aug 1999 13:55:24 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id PAA17498; Wed, 18 Aug 1999 15:55:02 +0200 (MET DST) Date: Wed, 18 Aug 1999 15:54:57 +0200 (MET DST) From: Gerald Pfeifer To: nbecker@fred.net cc: egcs@egcs.cygnus.com Subject: Re: pgcc status? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 16 Aug 1999 nbecker@fred.net wrote: > Is pgcc still alive? What is the status of back porting to gcc/egcs? > What about code fusion? Please have a look at the PentiumGCC FAQ. A link to the official PentiumGCC page is available from http://egcs.cygnus.com/egcstensions.html PentiumGCC is a separate, though related, project, different from EGCS resp. GCC. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9212-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 14:03:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18409 invoked by alias); 18 Aug 1999 14:03:14 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18392 invoked from network); 18 Aug 1999 14:03:12 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 18 Aug 1999 14:03:12 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA03701; Wed, 18 Aug 1999 07:02:59 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id HAA27937; Wed, 18 Aug 1999 07:02:58 -0700 (PDT) Date: Wed, 18 Aug 1999 07:02:58 -0700 (PDT) Message-Id: <199908181402.HAA27937@kankakee.wrs.com> To: nbecker@fred.net, pfeifer@dbai.tuwien.ac.at Subject: Re: pgcc status? Cc: egcs@egcs.cygnus.com > Date: Wed, 18 Aug 1999 15:54:57 +0200 (MET DST) > From: Gerald Pfeifer > To: nbecker@fred.net > cc: egcs@egcs.cygnus.com > Please have a look at the PentiumGCC FAQ. A link to the official > PentiumGCC page is available from > http://egcs.cygnus.com/egcstensions.html That link is now dead. :-( From gcc-return-9213-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 14:05:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19246 invoked by alias); 18 Aug 1999 14:05:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19223 invoked from network); 18 Aug 1999 14:05:54 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 18 Aug 1999 14:05:54 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id QAA17669; Wed, 18 Aug 1999 16:05:33 +0200 (MET DST) Date: Wed, 18 Aug 1999 16:05:28 +0200 (MET DST) From: Gerald Pfeifer To: Jonathan Bartlett cc: gcc@gcc.gnu.org, kenner@vlsi1.ultra.nyu.edu Subject: Re: Toy language In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 7 Aug 1999, Jonathan Bartlett wrote: > In case anyone's interested, I've updated the toy language(a short, > simple language meant to give an example of a GCC front-end) to work > with GCC 2.95. It is available at http://members.wri.com/johnnyb/compilers/ RTH beat me to it ;-), your page is now referenced from . Thanks! Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9214-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 14:09:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20159 invoked by alias); 18 Aug 1999 14:09: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20125 invoked from network); 18 Aug 1999 14:09:47 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 18 Aug 1999 14:09:47 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id QAA17758; Wed, 18 Aug 1999 16:09:17 +0200 (MET DST) Date: Wed, 18 Aug 1999 16:09:12 +0200 (MET DST) From: Gerald Pfeifer To: Mike Stump cc: nbecker@fred.net, egcs@egcs.cygnus.com Subject: Re: pgcc status? In-Reply-To: <199908181402.HAA27937@kankakee.wrs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 18 Aug 1999, Mike Stump wrote: >> http://egcs.cygnus.com/egcstensions.html > That link is now dead. :-( Uh? I tried just before sending my original message and just tried again: Both http://egcs.cygnus.com/egcstensions.html and the link from there to http://www.gcc.ml.org/ work fine for me. (Or did you mean to indicate that I should have used http://gcc.gnu.org/ instead of http://egcs.cygnus.com/ ?) Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9215-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 14:53:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31173 invoked by alias); 18 Aug 1999 14:53:24 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31062 invoked from network); 18 Aug 1999 14:53:09 -0000 Received: from eising.k-net.dtu.dk (HELO eising.k-net.dk) (130.225.71.227) by egcs.cygnus.com with SMTP; 18 Aug 1999 14:53:09 -0000 Received: (qmail 14649 invoked from network); 18 Aug 1999 14:54:22 -0000 Received: from carlsberg.kampsax.dtu.dk (qmailr@192.38.212.2) by eising.k-net.dk with SMTP; 18 Aug 1999 14:54:22 -0000 Received: (qmail 21289 invoked from network); 18 Aug 1999 14:52:45 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by carlsberg.kampsax.dtu.dk with SMTP; 18 Aug 1999 14:52:45 -0000 Received: from k4315.kampsax.dtu.dk (rask@192.38.215.253) by k4315.kampsax.dtu.dk with SMTP; 18 Aug 1999 14:51:09 -0000 Date: 18 Aug 99 16:50:25 +0100 From: "Rask Ingemann Lambertsen" Subject: Re: pgcc status? To: "GCC mailing list" In-Reply-To: Message-ID: <746.899T1266T10104626@kampsax.k-net.dk> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Organization: Me? Organised? Dream on... X-Files: The truth is out there. X-Mailer: THOR 2.5a (Amiga;TCP/IP) Den 18-Aug-99 15:09:12 skrev Gerald Pfeifer følgende om "Re: pgcc status?": > On Wed, 18 Aug 1999, Mike Stump wrote: >> That link is now dead. :-( > Uh? I tried just before sending my original message and just tried again: > Both http://egcs.cygnus.com/egcstensions.html and the link from there to > http://www.gcc.ml.org/ work fine for me. The latter one does look dead: The following error was encountered: Unable to determine IP address from host name for www.gcc.ml.org The dnsserver returned: DNS Domain 'www.gcc.ml.org' is invalid: Host not found (authoritative). Regards, Rask Ingemann Lambertsen E-mail: mailto:rask@kampsax.k-net.dk From gcc-return-9216-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 15:48:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12300 invoked by alias); 18 Aug 1999 15:48:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12277 invoked from network); 18 Aug 1999 15:48:11 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 18 Aug 1999 15:48:11 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id LAA20904; Wed, 18 Aug 1999 11:46:41 -0400 Message-ID: <37BAD6A5.315C3625@moberg.com> Date: Wed, 18 Aug 1999 11:52:05 -0400 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.9-19mdksmp i686) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org, libc-alpha@sourceware.cygnus.com Subject: Help: Unwinding the C++ stack...throw, longjmp & threads Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is a request for assistance, as I don't know the right person to ask. I'm working on a solution for deferred pthread_cancel() under Linux. What I want is to unwind the stack when the thread is cancelled so that C++ destructors for objects on the stack get called. If I recompile the C library with the -fexceptions flag, I can throw an exception in a cancellation handler, and this does what I want. My platform is Linux x86. However, after talking to Ulrich Drepper at LWCE, he says that recompiling the C library with -fexceptions slows it down by around 5%. So, obviously, he won't accept a patch to the main-line source to do this, with very good reason. I would like to write a function which unwinds the stack similarly to what happens at a throw in C++, but which wouldn't require recompiling existing libraries written in C. Is this possible? Can anyone point me to the source for how throw unwinds the stack? I've been looking at the egcs 1.1.2 source tree, but there's a lot to look at, and I'm confused with the different models for throw and catch. Alternatively, could someone put me in touch with the folks that work on C++ exceptions in gcc on the x86 processor? Also, does setjmp()/longjmp() assure that C++ destructors for stack-based objects are called? Sorry if some/all of these questions are dumb. Thanks. -- George T. Talbot From gcc-return-9217-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 18:54:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24911 invoked by alias); 18 Aug 1999 18:54:36 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24882 invoked from network); 18 Aug 1999 18:54:26 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 18 Aug 1999 18:54:26 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA09426; Wed, 18 Aug 1999 11:54:24 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id LAA20607; Wed, 18 Aug 1999 11:54:24 -0700 Date: Wed, 18 Aug 1999 11:54:24 -0700 From: Richard Henderson To: Rask Ingemann Lambertsen Cc: GCC mailing list Subject: Re: pgcc status? Message-ID: <19990818115424.C26368@cygnus.com> References: <746.899T1266T10104626@kampsax.k-net.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <746.899T1266T10104626@kampsax.k-net.dk>; from Rask Ingemann Lambertsen on Wed, Aug 18, 1999 at 04:50:25PM +0100 On Wed, Aug 18, 1999 at 04:50:25PM +0100, Rask Ingemann Lambertsen wrote: > The dnsserver returned: > DNS Domain 'www.gcc.ml.org' is invalid: Host not found (authoritative). It was certainly just a transient error -- Server: cygnus.com Address: 205.180.230.20 Non-authoritative answer: Name: goof.com Address: 12.4.218.41 Aliases: www.gcc.ml.org, www.goof.com r~ From gcc-return-9218-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 19:01:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26819 invoked by alias); 18 Aug 1999 19:00:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26773 invoked from network); 18 Aug 1999 19:00:51 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 18 Aug 1999 19:00:51 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA10239; Wed, 18 Aug 1999 12:00:50 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id MAA20614; Wed, 18 Aug 1999 12:00:50 -0700 Date: Wed, 18 Aug 1999 12:00:50 -0700 From: Richard Henderson To: "George T. Talbot" Cc: gcc@gcc.gnu.org, libc-alpha@sourceware.cygnus.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Message-ID: <19990818120050.D26368@cygnus.com> References: <37BAD6A5.315C3625@moberg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <37BAD6A5.315C3625@moberg.com>; from George T. Talbot on Wed, Aug 18, 1999 at 11:52:05AM -0400 On Wed, Aug 18, 1999 at 11:52:05AM -0400, George T. Talbot wrote: > I would like to write a function which unwinds the stack similarly to > what happens at a throw in C++, but which wouldn't require recompiling > existing libraries written in C. > > Is this possible? Possible using -fsjlj-exceptions, which is an abomination, so "no". > Also, does setjmp()/longjmp() assure that C++ destructors for > stack-based objects are called? No. We should instead figure out why the 5% performance degradation and fix it. IN THEORY, it shouldn't matter -- the complexity to compilation comes when you have exception handlers, not throws. We should not care that some called function throws through any more than we care if they longjmp though. Probably it is the case that some pass that has yet to be converted to the properly use the new CFG is misinterpreting basic block boundaries in the presence of flag_exceptions. r~ From gcc-return-9219-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 19:16:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30412 invoked by alias); 18 Aug 1999 19:16:05 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30354 invoked from network); 18 Aug 1999 19:15:56 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 18 Aug 1999 19:15:56 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA11689; Wed, 18 Aug 1999 12:15:56 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id MAA22047; Wed, 18 Aug 1999 12:15:56 -0700 To: "George T. Talbot" , drepper@cygnus.com Cc: gcc@gcc.gnu.org, libc-alpha@sourceware.cygnus.com, amacleod@cygnus.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BAD6A5.315C3625@moberg.com> From: Jason Merrill Date: 18 Aug 1999 12:15:56 -0700 In-Reply-To: "George T. Talbot"'s message of "Wed, 18 Aug 1999 11:52:05 -0400" Message-ID: Lines: 43 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> George T Talbot writes: > I'm working on a solution for deferred pthread_cancel() under Linux. > What I want is to unwind the stack when the thread is cancelled so that > C++ destructors for objects on the stack get called. > If I recompile the C library with the -fexceptions flag, I can throw an > exception in a cancellation handler, and this does what I want. My > platform is Linux x86. > However, after talking to Ulrich Drepper at LWCE, he says that > recompiling the C library with -fexceptions slows it down by around 5%. > So, obviously, he won't accept a patch to the main-line source to do > this, with very good reason. That doesn't make sense. Compiling C code with -fexceptions should not affect the code at all; it just creates unwind tables in another section. > I would like to write a function which unwinds the stack similarly to > what happens at a throw in C++, but which wouldn't require recompiling > existing libraries written in C. > Is this possible? Yes; gdb does it by looking at the code for the prologue and figuring out from there how registers have been saved. See i386_frame_find_saved_regs in gdb/i386-tdep.c. Adding generic unwind support would be most welcome. > Can anyone point me to the source for how throw unwinds the stack? See throw_helper in gcc/libgcc2.c. > Alternatively, could someone put me in touch with the folks that work on > C++ exceptions in gcc on the x86 processor? That would be Andrew Macleod and myself. > Also, does setjmp()/longjmp() assure that C++ destructors for > stack-based objects are called? You mean, explicit calls to setjmp and longjmp in user code? No. Jason From gcc-return-9220-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 19:26:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1123 invoked by alias); 18 Aug 1999 19:26:11 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1091 invoked from network); 18 Aug 1999 19:26:07 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 18 Aug 1999 19:26:07 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA12737; Wed, 18 Aug 1999 12:26:01 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id MAA22074; Wed, 18 Aug 1999 12:26:01 -0700 To: Richard Henderson Cc: "George T. Talbot" , gcc@gcc.gnu.org, libc-alpha@sourceware.cygnus.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BAD6A5.315C3625@moberg.com> <19990818120050.D26368@cygnus.com> From: Jason Merrill Date: 18 Aug 1999 12:26:01 -0700 In-Reply-To: Richard Henderson's message of "Wed, 18 Aug 1999 12:00:50 -0700" Message-ID: Lines: 34 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Richard Henderson writes: > We should instead figure out why the 5% performance degradation > and fix it. Agreed, though that isn't an option where we don't control libc. > IN THEORY, it shouldn't matter -- the complexity to compilation comes > when you have exception handlers, not throws. We should not care that > some called function throws through any more than we care if they > longjmp though. Agreed. > Probably it is the case that some pass that has yet to be > converted to the properly use the new CFG is misinterpreting > basic block boundaries in the presence of flag_exceptions. regmove.c says /* ??? We can't scan past the end of a basic block without updating the register lifetime info (REG_DEAD/basic_block_live_at_start). A CALL_INSN might be the last insn of a basic block, if it is inside an EH region. There is no easy way to tell, so we just always break when we see a CALL_INSN if flag_exceptions is nonzero. */ But as you say, this is unnecessary for code that contains no exception regions, such as all C code. That's the only case I found with a quick grep through the current mainline. Jason From gcc-return-9221-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 19:30:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2398 invoked by alias); 18 Aug 1999 19:30:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2369 invoked from network); 18 Aug 1999 19:30:17 -0000 Received: from waldo.fnal.gov (root@131.225.18.213) by egcs.cygnus.com with SMTP; 18 Aug 1999 19:30:16 -0000 Received: from wally.fnal.gov (kriol@wally [131.225.18.158]) by waldo.fnal.gov (8.8.8/8.8.8) with ESMTP id OAA24956; Wed, 18 Aug 1999 14:30:07 -0500 (CDT) Received: from localhost (kriol@localhost) by wally.fnal.gov (8.8.8/8.8.8) with ESMTP id OAA26402; Wed, 18 Aug 1999 14:30:06 -0500 (CDT) X-Authentication-Warning: wally.fnal.gov: kriol owned process doing -bs Date: Wed, 18 Aug 1999 14:30:05 -0500 (CDT) From: Oleg Krivosheev X-Sender: kriol@wally.fnal.gov To: "George T. Talbot" cc: gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads In-Reply-To: <37BAD6A5.315C3625@moberg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, On Wed, 18 Aug 1999, George T. Talbot wrote: > This is a request for assistance, as I don't know the right person to > ask. > > I'm working on a solution for deferred pthread_cancel() under Linux. > What I want is to unwind the stack when the thread is cancelled so that > C++ destructors for objects on the stack get called. > > If I recompile the C library with the -fexceptions flag, I can throw an > exception in a cancellation handler, and this does what I want. My > platform is Linux x86. > > However, after talking to Ulrich Drepper at LWCE, he says that > recompiling the C library with -fexceptions slows it down by around 5%. > So, obviously, he won't accept a patch to the main-line source to do > this, with very good reason. just curious, what exactly was measured and how? any details? > I would like to write a function which unwinds the stack similarly to > what happens at a throw in C++, but which wouldn't require recompiling > existing libraries written in C. > > Is this possible? Can anyone point me to the source for how throw > unwinds the stack? I've been looking at the egcs 1.1.2 source tree, but > there's a lot to look at, and I'm confused with the different models for > throw and catch. Alternatively, could someone put me in touch with the > folks that work on C++ exceptions in gcc on the x86 processor? > > Also, does setjmp()/longjmp() assure that C++ destructors for > stack-based objects are called? > > Sorry if some/all of these questions are dumb. Thanks. > > -- > George T. Talbot > OK From gcc-return-9222-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 21:07:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18518 invoked by alias); 18 Aug 1999 21:07:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18502 invoked from network); 18 Aug 1999 21:07:17 -0000 Received: from linuxpc1.lauterbach.com (qmailr@194.195.165.177) by egcs.cygnus.com with SMTP; 18 Aug 1999 21:07:16 -0000 Received: (qmail 20219 invoked from network); 18 Aug 1999 21:07:12 -0000 Received: from ns1090.munich.netsurf.de (HELO ns1102.munich.netsurf.de) (195.180.235.90) by linuxpc1 with SMTP; 18 Aug 1999 21:07:12 -0000 From: Franz Sirl To: Joern Rennecke Subject: Re: Deadly optimization bug (all gcc versions!) Date: Wed, 18 Aug 1999 22:43:55 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com References: <199908172246.XAA13829@phal.cygnus.co.uk> <99081801291800.04108@ns1102.munich.netsurf.de> In-Reply-To: <99081801291800.04108@ns1102.munich.netsurf.de> MIME-Version: 1.0 Message-Id: <99081823080500.00740@ns1102.munich.netsurf.de> Content-Transfer-Encoding: 8bit Am Mit, 18 Aug 1999 schrieb Franz Sirl: >This IF_THEN_ELSE doesn't look right to me. I'll continue debugging tomorrow, >it's already too late here :-). OK, it really happens in this code around line 6927 in if_then_else_cond(): /* Likewise for 0 or a single bit. */ else if (exact_log2 (nz = nonzero_bits (x, mode)) >= 0) { *ptrue = GEN_INT (nz), *pfalse = const0_rtx; return x; } nonzero_bits() calls get_last_value() on x with subst_low_cuid pointing to insn 14: (insn 11 10 14 (parallel[ (set (reg/v:SI 84) (and:SI (reg:SI 4 r4) (const_int 1 [0x1]))) (clobber (scratch:CC)) ] ) 121 {andsi3} (nil) (expr_list:REG_DEAD (reg:SI 4 r4) (expr_list:REG_UNUSED (scratch:CC) (nil)))) (insn 14 11 17 (set (reg/v:SI 85) (lshiftrt:SI (reg:SI 3 r3) (const_int 1 [0x1]))) 211 {lshrsi3_no_power} (nil) (expr_list:REG_DEAD (reg:SI 3 r3) (nil))) This means that nonzero_bits() will operate on insn 11 (which is returned by get_last_value) and return 1. However, it should return 3 for insn 17, as was the case before subst_low_cuid was lowered to insn 14 during the substition processing. (insn 17 14 20 (set (reg/v:SI 84) (plus:SI (reg/v:SI 84) (const_int 1 [0x1]))) 52 {*addsi3_internal1} (insn_list 11 (nil)) (nil)) (insn 20 17 22 (set (reg:SI 87) (lshiftrt:SI (reg/v:SI 84) (const_int 1 [0x1]))) 211 {lshrsi3_no_power} (insn_list 17 (nil)) (expr_list:REG_DEAD (reg/v:SI 84) (nil))) (insn 22 20 24 (set (reg:SI 86) (plus:SI (reg/v:SI 85) (reg:SI 87))) 52 {*addsi3_internal1} (insn_list 14 (insn_list 20 (nil))) (expr_list:REG_DEAD (reg/v:SI 85) (expr_list:REG_DEAD (reg:SI 87) (nil)))) Well, this is the analysis, however I have no idea how to fix it correctly :-(. A local fix in if_then_else_cond() would be to compare the results of nonzero_bits(x), reg_nonzero_bits[REGNO(x)] and reg_last_set_nonzero_bits[REGNO(x)] and use the biggest one? But this may just hide other potential problems with get_last_value()? Franz. From gcc-return-9223-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 21:11:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19600 invoked by alias); 18 Aug 1999 21:11:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19549 invoked from network); 18 Aug 1999 21:11:08 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 18 Aug 1999 21:11:08 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id XAA06269; Wed, 18 Aug 1999 23:07:31 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id XAA00686; Wed, 18 Aug 1999 23:04:05 +0200 Date: Wed, 18 Aug 1999 23:04:05 +0200 Message-Id: <199908182104.XAA00686@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: Stephan.Fuhrmann@stud.uni-karlsruhe.de CC: gcc@gcc.gnu.org In-reply-to: <28ae5fa4.u9t27e.2acae-fury@satyr.de> (s_fuhrm@ira.uka.de) Subject: Re: external template instantiation example?! References: <28ae5fa4.u9t27e.2acae-fury@satyr.de> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > Here's my question: how can I use 'class myclass' in 'myprog.cpp' > without instantiating the needed templates before manually? Can you > come up with an example? In C++, all templates must be defined at the `point of instantiation'; being merely declared is not enough. // myclass.h template class myclass { public: T a; void add(T b); }; template void myclass::add(T b) { a+=b; } // myprog.cpp #include "myclass.h" int main(int argc,char *argv[]) { myclass i; myclass c; c.add(2); i.add(1); i.add(c.a); return 0; } The example above compiles find on gcc 2.95, with no extra compiler flags. Regards, Martin P.S. This is a standard C++ question; please use comp.lang.c++ if you want to learn more about C++. From gcc-return-9224-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 21:16:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20746 invoked by alias); 18 Aug 1999 21:16:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20728 invoked from network); 18 Aug 1999 21:16:33 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 18 Aug 1999 21:16:33 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id XAA06693; Wed, 18 Aug 1999 23:12:31 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id XAA00783; Wed, 18 Aug 1999 23:10:43 +0200 Date: Wed, 18 Aug 1999 23:10:43 +0200 Message-Id: <199908182110.XAA00783@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: kabatek@chemie.uni-halle.de CC: gcc@gcc.gnu.org In-reply-to: (message from Ryszard Kabatek on Wed, 18 Aug 1999 14:34:19 +0200 (CEST)) Subject: Re: gcc-2.95 and -fhonor-std References: User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > I get a linker error if I try to use the -fhonor-std option. > I compiled the compiler with the standard options. > I get the error on Linux libc5 and glibc2 systems. > > Sould I compile the compiler with a special option? You only need to compile libgcc with -fhonor-std. Regards, Martin From gcc-return-9225-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 22:47:17 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5970 invoked by alias); 18 Aug 1999 22:47:16 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5955 invoked from network); 18 Aug 1999 22:47:15 -0000 Received: from unknown (HELO eta.ghs.com) (root@208.8.104.2) by egcs.cygnus.com with SMTP; 18 Aug 1999 22:47:15 -0000 Received: [from elbe.ghs.com (elbe.ghs.com [192.67.158.245]) by eta.ghs.com (eta-antispam 0.2) with ESMTP id PAA16758 for ; Wed, 18 Aug 1999 15:47:13 -0700 (PDT)] Received: from boson.ghs.com (boson.ghs.com [192.168.101.128]) by elbe.ghs.com (8.8.8/8.8.8) with SMTP id PAA19791 for ; Wed, 18 Aug 1999 15:47:12 -0700 (PDT) Message-ID: <37BB37EE.8D@mindspring.com> Date: Wed, 18 Aug 1999 15:47:10 -0700 From: Anton Staaf X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.7 sun4u) MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: new function attribute Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have been thinking it would be nice to have a new function attribute called no_ignore, that would cause a warning if a function was called and its return value was ignored. Is this something that interests you, or is it something that is already in the works? If its not already beeing worked on and you like the idea I would like to try adding it. -Anton From gcc-return-9226-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 18 22:54:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9597 invoked by alias); 18 Aug 1999 22:54:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9546 invoked from network); 18 Aug 1999 22:54:55 -0000 Received: from atlrel1.hp.com (156.153.255.210) by egcs.cygnus.com with SMTP; 18 Aug 1999 22:54:55 -0000 Received: from toolbox.rsn.hp.com (toolbox.rsn.hp.com [15.99.151.117]) by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id SAA27404 for ; Wed, 18 Aug 1999 18:54:19 -0400 (EDT) Received: from toolbox (localhost) by toolbox.rsn.hp.com with SMTP (1.39.111.2/16.2) id AA019246890; Wed, 18 Aug 1999 17:54:51 -0500 Message-Id: <37BB39BA.4193@rsn.hp.com> Date: Wed, 18 Aug 1999 17:54:50 -0500 From: Piotr Findeisen Organization: HP Richardson X-Mailer: Mozilla 3.04Gold (X11; I; HP-UX B.10.01 9000/712) Mime-Version: 1.0 To: gcc@gcc.gnu.org Subject: successful build of gcc-2.95.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry if you are getting this twice - here's the output from config.guess: hppa1.1-hp-hpux10.01 Thanks! Piotr Findeisen Hewlett-Packard Company High-End Performance Section 3000 Waterview Parkway E-mail: piotr@rsn.hp.com Phone: (972) 497-4476 P.O.Box 833851 Fax: (972) 497-4245 Richardson, Texas 75083-3851 From gcc-return-9227-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 02:37:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13501 invoked by alias); 19 Aug 1999 02:37:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13486 invoked from network); 19 Aug 1999 02:37:26 -0000 Received: from nuxi.cs.ucdavis.edu (HELO relay.nuxi.com) (@169.237.7.38) by egcs.cygnus.com with SMTP; 19 Aug 1999 02:37:26 -0000 Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id TAA51161 for gcc@gcc.gnu.org; Wed, 18 Aug 1999 19:37:25 -0700 (PDT) (envelope-from obrien) Message-ID: <19990818193725.A51139@nuxi.com> Date: Wed, 18 Aug 1999 19:37:25 -0700 From: "David O'Brien" To: gcc@gcc.gnu.org Subject: DBX directives Reply-To: obrien@NUXI.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Should one use "#define DBX_DEBUGGING_INFO" or "#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG". I am looking at this for FreeBSD/Alpha. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) From gcc-return-9228-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 05:44:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1651 invoked by alias); 19 Aug 1999 05:44:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1632 invoked from network); 19 Aug 1999 05:44:28 -0000 Received: from dhcp-sv-18.cygnus.com (HELO upchuck.cygnus.com) (205.180.231.98) by egcs.cygnus.com with SMTP; 19 Aug 1999 05:44:27 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id XAA01549; Wed, 18 Aug 1999 23:43:53 -0600 To: obrien@NUXI.com cc: gcc@gcc.gnu.org Subject: Re: DBX directives Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 18 Aug 1999 19:37:25 PDT. <19990818193725.A51139@nuxi.com> Date: Wed, 18 Aug 1999 23:43:52 -0600 Message-ID: <1546.935041432@upchuck.cygnus.com> From: Jeffrey A Law In message <19990818193725.A51139@nuxi.com>you write: > Should one use "#define DBX_DEBUGGING_INFO" or "#define > PREFERRED_DEBUGGING_TYPE DBX_DEBUG". I am looking at this for > FreeBSD/Alpha. DBX_DEBUGGING_INFO. The second is supposed to be needed iff the port supports multiple debug formats. jeff From gcc-return-9229-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 06:05:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4728 invoked by alias); 19 Aug 1999 06:05:02 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4712 invoked from network); 19 Aug 1999 06:05:01 -0000 Received: from nuxi.cs.ucdavis.edu (HELO relay.nuxi.com) (@169.237.7.38) by egcs.cygnus.com with SMTP; 19 Aug 1999 06:05:01 -0000 Received: from dragon.nuxi.com (iras-2-79.ucdavis.edu [169.237.16.207]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id XAA51776; Wed, 18 Aug 1999 23:04:59 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id XAA73667; Wed, 18 Aug 1999 23:04:53 -0700 (PDT) (envelope-from obrien) Date: Wed, 18 Aug 1999 23:04:52 -0700 From: "David O'Brien" To: Jeffrey A Law Cc: gcc@gcc.gnu.org Subject: Re: DBX directives Message-ID: <19990818230452.B64369@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <19990818193725.A51139@nuxi.com> <1546.935041432@upchuck.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <1546.935041432@upchuck.cygnus.com>; from Jeffrey A Law on Wed, Aug 18, 1999 at 11:43:52PM -0600 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 > > Should one use "#define DBX_DEBUGGING_INFO" or "#define > > PREFERRED_DEBUGGING_TYPE DBX_DEBUG". I am looking at this for > > FreeBSD/Alpha. > DBX_DEBUGGING_INFO. Right now the tm.h list is: alpha/alpha.h svr4.h alpha/freebsd.h (svr4.h is there because it was in the FreeBSD/i386 case) svr4.h defines just about all the *_DEBUGGING_INFO macros. It seems that many ELF platform includes svr4.h for ELF definitions. Should svr4.h be defining so much about the environment? Or should I move away from svr4.h, moving maybe 1/2 of its contents into freebsd.h? -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) From gcc-return-9230-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 06:49:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9275 invoked by alias); 19 Aug 1999 06:49:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9252 invoked from network); 19 Aug 1999 06:49:37 -0000 Received: from rumcajs.chemie.uni-halle.de (rysio@141.48.254.65) by egcs.cygnus.com with SMTP; 19 Aug 1999 06:49:37 -0000 Received: from localhost (rysio@localhost) by rumcajs.chemie.uni-halle.de (8.9.0/8.8.8) with SMTP id IAA22684; Thu, 19 Aug 1999 08:48:37 +0200 Date: Thu, 19 Aug 1999 08:48:36 +0200 (CEST) From: Ryszard Kabatek Reply-To: Ryszard Kabatek To: "Martin v. Loewis" cc: gcc@gcc.gnu.org Subject: Re: gcc-2.95 and -fhonor-std In-Reply-To: <199908182110.XAA00783@mira.isdn.cs.tu-berlin.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 18 Aug 1999, Martin v. Loewis wrote: > > I get a linker error if I try to use the -fhonor-std option. > > I compiled the compiler with the standard options. > > I get the error on Linux libc5 and glibc2 systems. > > > > Sould I compile the compiler with a special option? > > You only need to compile libgcc with -fhonor-std. > > Regards, > Martin > Is there an option for the configure script to do it during the compilation of the compiler? Ryszard Kabatek Martin-Luther University Halle-Wittenberg, Department of Physical Chemistry Geusaer Str. 88, 06217 Merseburg, Germany Tel. +49 3461 46 2466 Fax. +49 3461 46 2129 From gcc-return-9231-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 06:59:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11988 invoked by alias); 19 Aug 1999 06:59:44 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11972 invoked from network); 19 Aug 1999 06:59:43 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 19 Aug 1999 06:59:43 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id IAA17043; Thu, 19 Aug 1999 08:55:06 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id IAA00528; Thu, 19 Aug 1999 08:53:05 +0200 Date: Thu, 19 Aug 1999 08:53:05 +0200 Message-Id: <199908190653.IAA00528@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: kabatek@chemie.uni-halle.de CC: gcc@gcc.gnu.org In-reply-to: (message from Ryszard Kabatek on Thu, 19 Aug 1999 08:48:36 +0200 (CEST)) Subject: Re: gcc-2.95 and -fhonor-std References: User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > Is there an option for the configure script to do it during > the compilation of the compiler? No. The easiest way is to change the value of flag_honor_std in gcc/cp/decl2.c before building the compiler. Regards, Martin From gcc-return-9232-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 07:20:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15661 invoked by alias); 19 Aug 1999 07:20:46 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15643 invoked from network); 19 Aug 1999 07:20:39 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 19 Aug 1999 07:20:39 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id JAA18642; Thu, 19 Aug 1999 09:15:05 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id JAA00571; Thu, 19 Aug 1999 09:14:12 +0200 Date: Thu, 19 Aug 1999 09:14:12 +0200 Message-Id: <199908190714.JAA00571@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: astaaf@mindspring.com CC: gcc@gcc.gnu.org In-reply-to: <37BB37EE.8D@mindspring.com> (message from Anton Staaf on Wed, 18 Aug 1999 15:47:10 -0700) Subject: Re: new function attribute References: <37BB37EE.8D@mindspring.com> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > I have been thinking it would be nice to have a new function > attribute called no_ignore, that would cause a warning if a function > was called and its return value was ignored. Is this something that > interests you, or is it something that is already in the works? As far as I know, this is not yet being considered. You won't get universal approvement that it is a good idea. Instead, the criteria for accepting or rejecting it will be more the the traditional ones: Is there a clear definition of the feature (also in terms of documentation)? Does the implementation really implement the feature? Does it interact with other features in a non-intuitive way (which wouldn't be good)? Did you submit a copyright disclaimer? If you think you can meet this and similar criteria, I'd say: go ahead and implement it. When you are done, submit a patch to gcc-patches@gcc.gnu.org, and the GCC maintainers will eventually look at it. When you do so, don't get discouraged by a long period of silence afterwards - the (few) maintainers have typically a long backlog of patches that need to be investigated. Hope this helps, Martin From gcc-return-9233-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 07:52:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22757 invoked by alias); 19 Aug 1999 07:52:20 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22700 invoked from network); 19 Aug 1999 07:52:12 -0000 Received: from chewbacca.hagos.de (194.45.217.99) by egcs.cygnus.com with SMTP; 19 Aug 1999 07:52:12 -0000 Received: from hagos.de (jabba.linux.hagos.de [192.168.100.19]) by chewbacca.hagos.de (8.8.8/8.8.8) with ESMTP id JAA02944 for ; Thu, 19 Aug 1999 09:51:42 +0200 Message-ID: <37BBB78A.2D1ED84C@hagos.de> Date: Thu, 19 Aug 1999 09:51:38 +0200 From: Klaus Muth X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.9 i586) X-Accept-Language: de, en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Compiled gcc 2.95 on Solaris 2.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, according to http://egcs.cygnus.com/gcc-2.95/buildstat.html (08/17/1999), ther has been no report for successfull build on Solaris2.4. I had no problems with it (ok, it was painful to build gcc2.8.1 with no compiler for 2.4 :). Here is my architecture: sparc-sun-solaris2.4 I used gcc 2.8.1 & GNU binutils 2.9.1.0.19a klaus -- mit freundlichen Gruessen, Klaus Muth HAGOS eG Industriestr. 62 fon: (+49) 711 78805-86 EDV-Programmierung D-70565 Stuttgart fax: (+49) 711 78805-99 http://www.hagos.de Germany mailto:muth@hagos.de ----------------------------------------------------------------------- Hey, the still use those sparc-sun-solaris2.4 systems out there! From gcc-return-9234-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 10:13:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4318 invoked by alias); 19 Aug 1999 10:13:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4303 invoked from network); 19 Aug 1999 10:13:28 -0000 Received: from bubble.ndsuk.com (194.216.129.248) by egcs.cygnus.com with SMTP; 19 Aug 1999 10:13:28 -0000 Received: from SMTP (emma.hedge.ndsuk.com [172.17.253.25]) by bubble.ndsuk.com (8.8.7/8.8.7) with SMTP id KAA02166; Thu, 19 Aug 1999 10:13:26 GMT Received: from sage.hedge.ndsuk.com ([172.17.253.10]) by 172.17.253.25 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 19 Aug 1999 10:07:36 0000 (GMT) Received: from ibm.net (ndsuk4908.stone.ndsuk.com [172.16.195.75]) by sage.hedge.ndsuk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QW2H2CXZ; Thu, 19 Aug 1999 11:13:17 +0100 Message-ID: <37BBD8B8.B6FA4DFE@ibm.net> Date: Thu, 19 Aug 1999 11:13:12 +0100 From: Etienne Lorrain Organization: Protection of the "jnp" instruction league X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org, gnu-gcc-bug@gnu.org Subject: attribute ((packed)) on variables Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have reported, quite a long time ago, a problem when you try to get a short alignement (or no alignment) on variables: http://www.progressive-comp.com/Lists/?l=egcs-bugs&m=91303898717233&w=3 When you read documentation, it is done by: struct my_struct_type my_struct attribute ((packed)); It could be done by struct my_struct_type my_struct attribute ((aligned(1))); but usually "attribute ((aligned(x)))" is to specify the minimum alignment needed. None of these two method works (the test case is in the http address), and I really do not want my structure aligned, mostly 32 bytes aligned. I stoped complaining when someone told me in private that the problem was corrected in GCC-2.95, but now I am using this compiler and it is still not working... Someone has a solution? (other than using "sed" on the assembler file). Thanks, Etienne. From gcc-return-9235-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 14:57:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32013 invoked by alias); 19 Aug 1999 14:57:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31996 invoked from network); 19 Aug 1999 14:57:46 -0000 Received: from newton.math.purdue.edu (root@128.210.3.6) by egcs.cygnus.com with SMTP; 19 Aug 1999 14:57:46 -0000 Received: from polya.math.purdue.edu (lucier@polya.math.purdue.edu [128.210.3.194]) by newton.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.3) with ESMTP id JAA28403; Thu, 19 Aug 1999 09:57:42 -0500 (EST) Received: (from lucier@localhost) by polya.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.1) id JAA10650; Thu, 19 Aug 1999 09:57:42 -0500 (EST) Date: Thu, 19 Aug 1999 09:57:42 -0500 (EST) From: Brad Lucier Message-Id: <199908191457.JAA10650@polya.math.purdue.edu> To: gcc@gcc.gnu.org Subject: sqrt on alphaev6 Cc: lucier@math.purdue.edu with -mcpu=ev6 -mieee on alphaev6 with gcc 2.95.1 the following code is typically generated for sqrt: sqrttsu $f16,$f0 cmpteqsu $f0,$f0,$f10 ; check for NaN? fbne $f10,$L836 jsr $26,sqrt ldgp $29,0($26) $L836: My question is whether the call to the sqrt routines is necessary for ev6. I find 21264hrm.pdf to be somewhat confusing, but it seems to imply that software completion is not needed on the 21264. Brad Lucier lucier@math.purdue.edu From gcc-return-9236-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 15:04:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 604 invoked by alias); 19 Aug 1999 15:04:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 588 invoked from network); 19 Aug 1999 15:04:06 -0000 Received: from pimout2-ext.prodigy.net (HELO pimout2-int.prodigy.net) (207.115.59.113) by egcs.cygnus.com with SMTP; 19 Aug 1999 15:04:06 -0000 Received: from default (TULSB102-16.splitrock.net [209.156.87.16]) by pimout2-int.prodigy.net (8.8.5/8.8.5) with ESMTP id LAA711186 for ; Thu, 19 Aug 1999 11:04:03 -0400 Message-Id: <199908191504.LAA711186@pimout2-int.prodigy.net> From: "Dean Piper" To: Subject: configuring C++ download Date: Thu, 19 Aug 1999 10:07:54 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1162 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit HELP! I'm can't figure out how your instructions on configuring, building and installing the compiler program I downloaded. I downloaded the "EGCS 1.1.2 to GCC 2.95 diffs, gzip format, 7.0 meg The only zip program my computer has is WINZIP. I have windows 95 and Microsoft programs . I went into msdos prompt and was able to mkdir objdir.cc and cd objdir.cc I couldn't get any further other than to mkdir srcdir.cc but the configure command just won't work in my system. I want to be able to write and run C or C++ programs, but I don't know how to get this compiler working. Any suggestions will be very appreciated. Amy Piper pipercubs@prodigy.net From gcc-return-9237-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 15:06:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1477 invoked by alias); 19 Aug 1999 15:06:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1454 invoked from network); 19 Aug 1999 15:05:58 -0000 Received: from fyserv1.fy.chalmers.se (129.16.110.66) by egcs.cygnus.com with SMTP; 19 Aug 1999 15:05:58 -0000 Received: from fy.chalmers.se (unimon [129.16.114.105]) by fyserv1.fy.chalmers.se (8.8.8/8.8.8) with ESMTP id RAA05941; Thu, 19 Aug 1999 17:05:56 +0200 (MET DST) Message-ID: <37BC1D55.9C49EED1@fy.chalmers.se> Date: Thu, 19 Aug 1999 17:05:57 +0200 From: Andy Polyakov X-Mailer: Mozilla 4.08C-SGI [en] (X11; U; IRIX 6.5 IP32) MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: alignment on Solaris x86 Content-Type: multipart/mixed; boundary="------------6CF473AE10111A1E9E61EDAB" This is a multi-part message in MIME format. --------------6CF473AE10111A1E9E61EDAB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, everybody! As it doesn't seem to be news (just figured that the problem was already reported and fixed) I post it here at general discussion list. It's just a short story about how much misalignment of floating point variables on Intel can cost. Those who hate HTML attachments can read it on http://fy.chalmers.se/~appro/gcc-2.95.html. Cheers. Andy. P.S. Just double checked 2.95.1 in this last second. Even though http://egcs.cygnus.com/ml/gcc-patches/1999-07/msg00733.html claims similar (to mine) fix was applied it's not in 2.95.1! --------------6CF473AE10111A1E9E61EDAB Content-Type: text/html; charset=us-ascii; name="gcc-2.95.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gcc-2.95.html" Content-Base: "http://fy/~appro/gcc-2.95.html" How can two lines make your code run 25% faster on Solaris x86

    How can two lines make your code run 25% faster

    A friend of mine loves to benchmark his programs on different computer platforms and compilers. Some time ago he took advantage of Sun's promotion offer and obtained and installed Solaris 7 on his brand new Pentium-II home computer. At work he has to use Windows NT though. For this reason I used to ask him various small questions about NT and he used to answer "It's a professional operating system, you know. Everything has to be slow and take a lot of memory." When he installed Solaris 7 and I asked him how it felt he replied "Well... It seems to be a professional operating system. Everything is slow and takes a lot of memory." I asked "What's slow?" as I already knew it takes memory. It turned that the very first thing he did was compile the program he was benchmarking under Linux on the very same computer (I should have guessed:-) and found that it goes 33% slower. Yes, he was using same compiler, namely egcs-1.1.2... I myself use Solaris at work and even though I use SPARC version I felt slightly embarrassed and responsible as it was actually me who has encouraged him to install Solaris x86. No, 33% is no excuse even for a "professional" system, you know...

    My first move was "professional system needs a professional compiler." So I've persuaded him to download the trial version of Workshop for Intel. No, I wasn't expecting him to pay 1.395USD for a program to use at home, this 33% simply were bugging me (as well as him) that much... Workshop C exhibited 15% improvement over egcs-1.1.2 but was still way (well, your milage may vary) behind Linux. Something you don't want to learn about software after you've paid good money for it, huh?

    But what does his program do? It's floating point intensive, it's C... He must have passed floating point arguments by value and/or had some local floating point variables... And it suddenly strikes me! All those arguments and local variables reside in stack and how the hell are they aligned? I reported myself that egcs doesn't keep track of it and they (variables) may or may not be aligned. Good news were that we alredy knew they were working on it since a while ago:

    March 23, 1999
    Through the efforts of John Wehle and Bernd Schmidt, GCC will now attempt to keep the stack 64bit aligned on the x86 and allocate doubles on 64bit boundaries. This can significantly improve floating point performance on the x86. Work will continue on aligning the stack and floating point values in the stack.

    So next move was naturally to download gcc-2.95... In couple of hours my friend reported that on Linux his program runs 8% faster and my test program (from the bug report) exhibits perfect alignment of local variables. I was impatiently waiting for results from Solaris... An hour and a half passed... Yes! He calls and says it's 8% improvement on Solaris as well (i.e. the very same 33% behind Linux), but local variables turned out to be misaligned:-( How come?

    Well, the question is how does this "attempt to keep the stack 64bit aligned" work? I could think of two ways. One can align it in every function with something like "movl %esp,%eax; andl $-8,%esp; pushl %eax" and then "popl %eax; movl %eax,%esp" at return. Or one can simply preserve alignment at some reference point. It looks like gcc-2.95 assumes and preserves double alignement of first argument passed to any particular function. And all one has to do is to make sure fist argument to main() is double aligned:

    gcc-2.95.perf.patch
    *** ./gcc/config/i386/sol2-c1.asm.orig Wed Dec 16 22:04:08 1998 --- ./gcc/config/i386/sol2-c1.asm Thu Aug 12 23:39:02 1999 *************** *** 59,64 **** --- 59,70 ---- pushl $0x0 movl %esp,%ebp + ! Make sure the first argument to main is double aligned. I've counted 5 + ! pushes in the original code so if I "issue" one more it's set. + ! <appro@fy.chalmers.se> + andl $-8,%esp + subl $4,%esp + ! As specified per page 3-32 of the ABI, %edx contains a function ! pointer that should be registered with atexit(), for proper ! shared object termination. Just push it onto the stack for now *** ./gcc/config/i386/sol2-gc1.asm.orig Wed Dec 16 22:04:12 1998 --- ./gcc/config/i386/sol2-gc1.asm Thu Aug 12 23:39:18 1999 *************** *** 62,67 **** --- 62,73 ---- pushl $0x0 movl %esp,%ebp + ! Make sure the first argument to main is double aligned. I've counted 5 + ! pushes in the original code so if I "issue" one more it's set. + ! <appro@fy.chalmers.se> + andl $-8,%esp + subl $4,%esp + ! As specified per page 3-32 of the ABI, %edx contains a function ! pointer that should be registered with atexit(), for proper ! shared object termination. Just push it onto the stack for now

    This was my present to my friend's birthday. Now his program runs only 5% slower on Solaris than on Linux:-) So those 5% is how much proffesional system should cost nowadays, huh?

    Andy. Doing his an(d)ything:-)
    --------------6CF473AE10111A1E9E61EDAB-- From gcc-return-9238-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 15:17:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4166 invoked by alias); 19 Aug 1999 15:17:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4147 invoked from network); 19 Aug 1999 15:17:48 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 19 Aug 1999 15:17:48 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id LAA00994; Thu, 19 Aug 1999 11:15:00 -0400 Message-ID: <37BC20BA.E8C4E7F2@moberg.com> Date: Thu, 19 Aug 1999 11:20:26 -0400 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.9-19mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Oleg Krivosheev CC: gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com, drepper@cygnus.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oleg Krivosheev wrote: > > Hi, > > On Wed, 18 Aug 1999, George T. Talbot wrote: > > > This is a request for assistance, as I don't know the right person to > > ask. > > > > I'm working on a solution for deferred pthread_cancel() under Linux. > > What I want is to unwind the stack when the thread is cancelled so that > > C++ destructors for objects on the stack get called. > > > > If I recompile the C library with the -fexceptions flag, I can throw an > > exception in a cancellation handler, and this does what I want. My > > platform is Linux x86. > > > > However, after talking to Ulrich Drepper at LWCE, he says that > > recompiling the C library with -fexceptions slows it down by around 5%. > > So, obviously, he won't accept a patch to the main-line source to do > > this, with very good reason. > > just curious, what exactly was measured and how? I don't know. Mr. Drepper, can you tell us what was measured? Was this with the new exception model or the old setjmp()/longjmp() exception model? -- George T. Talbot From gcc-return-9239-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 15:33:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6485 invoked by alias); 19 Aug 1999 15:33:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6468 invoked from network); 19 Aug 1999 15:33:15 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 19 Aug 1999 15:33:15 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id LAA01132; Thu, 19 Aug 1999 11:31:42 -0400 Message-ID: <37BC24A4.71A04022@moberg.com> Date: Thu, 19 Aug 1999 11:37:08 -0400 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.9-19mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org, libc-alpha@sourceware.cygnus.com CC: Ulrich Drepper , Dave Butenhof , george@moberg.com Subject: FWD: Dave Butenhof (author of Programming with POSIX Threads) on C++ and pthread_cancel() Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've got this book called "Programming with POSIX Threads" by Dave Butenhof. It's really good, so I thought I'd run the whole thread cancellation issue past him. I asked him if it would be OK to forward his reply to the lists, and he said it was OK, so here it is... -- George T. Talbot P.S. From what I can glean from replies on the list, the current thread-safe exception model in GCC does not use setjmp()/longjmp() and doesn't have runtime cost for declaring an exception scope. -------- Original Message -------- Subject: Re: Question about your book... Date: Wed, 18 Aug 1999 13:59:48 -0400 From: Dave Butenhof Organization: Compaq Computer Corporation To: "George T. Talbot" References: <3758014E.51BFC7C3@compaq.com> <37BADDE2.205C9974@moberg.com> "George T. Talbot" wrote: > Dear Mr. Butenhof, > > I've contacted you before on the issue of thread cancellation and C++, > and I have another question, if you don't mind. > > I've been revisiting thread cancellation and C++ on Linux. What is the > correct behaviour for C++ when a thread is cancelled? I.E. In an ideal > world what effect on C++ code should pthread_cancel() in deferred > cancellation mode have? > > 1) Run all the destructors for objects on the stack and all code in the > catch (...) handlers? > 2) Run all the destructors for objects on the stack? > 3) Nothing? > 4) Segfault? ;^) Yes, in an ideal world, all actions would segfault. That would make coding and debugging easy. (Write anything. It segfaults. Good; it was supposed to. Done with that. On to the next project. ;-) ) MY ideal behavior, and the one towards which I'm working on Tru64 UNIX, is, more or less, your "1". Actually, "1" is what happens with the current OS and C++ release. We're working on moving beyond that to make cancellation (and other system/thread exceptions) known C++ exception classes so that you could write something like "catch(POSIX_cancel) {}" instead of anonymously catching all exceptions. I know others, though, who believe that cancellation shouldn't be catch-able (anonymously or otherwise), and should only run destructors. That's your "2". I don't know of anyone who believes that cancellation shouldn't be required to run destructors. (And if there are any, they're wrong.) Although I don't agree with the idea of "hiding" cancellation exceptions, at least "2" would allow writing cancel-safe code. So I'd have to say that 1 is "near-ideal" (but not as good as making cancel a real C++ exception), 2 is "acceptable". The others are not. > Right now, pthreads under Linux does 3. I've been fooling around with > the implementation, and if I recompile the C library with exception > support (-fexceptions), and have pthread_cancel() do a throw as its last > action after running the cancellation handlers, I can get it to do 1). Interleaved C++ destructors and POSIX cleanup handlers should be run in proper nested order, from inner to outer, in one pass. (They're not "cancellation handlers", by the way, because they're also run by thread exit, and should be run any time an exception propagates through the code scope.) I don't believe it's acceptable to run all cleanup handlers first, then all destructors... or vice versa. Ideally, both are implemented as exception handlers, and the exception propagates normally as one would expect an exception to propagate. One option, when you're using just C++, is to have pthread_cleanup_push() to expand to a block containing a local object with a destructor. The pthread_cleanup_pop() macro would expand to terminate the block. Exiting the scope would then run the object destructor. On normal exit, it would check the pop argument to determine whether to call the cleanup handler; otherwise it'd always call the handler. But that won't help if you have interleaved C and C++ code, unless both languages support a common exception model. That's what we do on Tru64 UNIX, because the underlying common calling standard supports exceptions, and the C compiler provides extensions to declare essentially try/catch scopes. > However the maintainer of the GNU C library won't enable exception > support in the main-line version, as he says it slows down the library > by about 5%. Also, it's been really obvious that the maintainer and > others working on the C library and gcc don't like C++, so I'm kind-of > on my own with this. I don't know what this -fexceptions option does on Linux, but it sounds like it's NOT real exceptions. Maybe something based on setjmp/longjmp. Real exceptions don't have performance overhead (except indirectly via a small increase in object size) until an exception is raised. Exception scopes should be PC mapped, so there's no runtime cost to declare a scope; when an exception is raised, the common exception library can walk the stack and check for exception code ranges to do the proper unwind actions. Too bad. Any system without well-defined "native" exception support is going to have a hard time doing C++ (or Ada, or Modula-2+) at all well. Exceptions need to be free (or very nearly free) until you actually raise one. > I'm hoping that I can figure out a way to unwind the stack and call > destructors, which I might be able to get into a patch, but I'm not > clear on the correct behaviour. You need to be able to unwind the thread's stack one frame at a time, and detect a C++ catch, destructor, or cleanup handler (or any combination) in each frame. Then activate that handler, then unwind to the next frame, and so forth. If you can do a stack walk, you're halfway there; you just need to be able to identify both the C++ and cleanup information. Without real exceptions, most likely the C runtime has some list of setjmp blocks, and the thread library has its own list of setjmp blocks. You'd need to be able to find both lists, and traverse them both to find all the blocks for each frame as you walk the stack. > Thanks for your time. Sorry if I'm adding to an overly full mailbox. That's OK. Good luck! /---------------------------[ Dave Butenhof ]--------------------------\ | Compaq Computer Corporation David.Butenhof@compaq.com | | 110 Spit Brook Rd ZKO2-3/Q18 http://members.aol.com/drbutenhof | | Nashua NH 03062-2698 http://www.awl.com/cseng/titles/0-201-63392-2/ | \-----------------[ Better Living Through Concurrency ]----------------/ From gcc-return-9240-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 15:54:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9806 invoked by alias); 19 Aug 1999 15:54:30 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9775 invoked from network); 19 Aug 1999 15:54:21 -0000 Received: from dhcp-sv-18.cygnus.com (HELO upchuck.cygnus.com) (205.180.231.98) by egcs.cygnus.com with SMTP; 19 Aug 1999 15:54:21 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id JAA03744 for ; Thu, 19 Aug 1999 09:54:13 -0600 To: gcc@gcc.gnu.org Reply-To: law@cygnus.com Subject: GCC/EGCS Downtime Date: Thu, 19 Aug 1999 09:54:13 -0600 Message-ID: <3741.935078053@upchuck.cygnus.com> From: Jeffrey A Law I'm going to be taking the GCC/EGCS box down a couple times today for short periods of time to give the machine a little TLC. I'll give everyone as much notice as I can before I bounce the box. jeff From gcc-return-9241-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 16:23:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1069 invoked by alias); 19 Aug 1999 16:22:21 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1020 invoked from network); 19 Aug 1999 16:22:10 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 19 Aug 1999 16:22:10 -0000 Received: from otr.mynet (dialin-sv-02.cygnus.com [205.180.231.52]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA12966; Thu, 19 Aug 1999 09:12:40 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.9.3/8.9.3/ud-990718) id JAA10780; Thu, 19 Aug 1999 09:10:10 -0700 To: "George T. Talbot" Cc: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Ulrich Drepper Date: 19 Aug 1999 09:10:10 -0700 In-Reply-To: "George T. Talbot"'s message of "Thu, 19 Aug 1999 11:20:26 -0400" Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Big Bend" "George T. Talbot" writes: > I don't know. Mr. Drepper, can you tell us what was measured? Was this > with the new exception model or the old setjmp()/longjmp() exception > model? I don't remember. One of the things which was measured for sure is code/data size and this went up. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gcc-return-9242-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 16:47:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8824 invoked by alias); 19 Aug 1999 16:46:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8066 invoked from network); 19 Aug 1999 16:46:33 -0000 Received: from sunsite.ms.mff.cuni.cz (195.113.19.66) by egcs.cygnus.com with SMTP; 19 Aug 1999 16:46:33 -0000 Received: (from jj@localhost) by sunsite.ms.mff.cuni.cz (8.9.3/8.9.3) id SAA31451; Thu, 19 Aug 1999 18:44:10 +0200 Date: Thu, 19 Aug 1999 18:44:09 +0200 From: Jakub Jelinek To: Ulrich Drepper Cc: "George T. Talbot" , Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Message-ID: <19990819184409.X548@mff.cuni.cz> References: <37BC20BA.E8C4E7F2@moberg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from Ulrich Drepper on Thu, Aug 19, 1999 at 09:10:10AM -0700 On Thu, Aug 19, 1999 at 09:10:10AM -0700, Ulrich Drepper wrote: > "George T. Talbot" writes: > > > I don't know. Mr. Drepper, can you tell us what was measured? Was this > > with the new exception model or the old setjmp()/longjmp() exception > > model? > > I don't remember. One of the things which was measured for sure is > code/data size and this went up. One thing which is IMHO wrong is that gcc above egcs-1.1.2 emits .eh_frame if one compiles c with -g -fno-exception. glibc makes great distinction between routines where exceptions can be thrown through and other routines, but if one compiles glibc with -g, it will not make any difference. If I strip it down later, the .eh_frame section will obviously stay in including its .rela.eh_frame which will be relocated during glibc relocation. Is it possible to emit the frame info into .dwarf_frame if exceptions are not enabled instead of .eh_frame, so that the section will be loaded only when debugging, can be stripped off and does not have to be relocated in the common case? So far gdb does not use it anyway (I was told it should do that in the future though). Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz Administrator of SunSITE Czech Republic, MFF, Charles University ___________________________________________________________________ UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/ Linux version 2.3.13 on a sparc64 machine (1343.49 BogoMips) ___________________________________________________________________ From gcc-return-9243-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 18:36:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24360 invoked by alias); 19 Aug 1999 18:35:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24213 invoked from network); 19 Aug 1999 18:35:26 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 19 Aug 1999 18:35:26 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id OAA03024; Thu, 19 Aug 1999 14:33:48 -0400 Message-ID: <37BC4F54.F169A2C0@moberg.com> Date: Thu, 19 Aug 1999 18:39:16 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jason Merrill CC: Richard Henderson , gcc@gcc.gnu.org, libc-alpha@sourceware.cygnus.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BAD6A5.315C3625@moberg.com> <19990818120050.D26368@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jason Merrill wrote: > > >>>>> Richard Henderson writes: > > > We should instead figure out why the 5% performance degradation > > and fix it. > > Agreed, though that isn't an option where we don't control libc. > > > IN THEORY, it shouldn't matter -- the complexity to compilation comes > > when you have exception handlers, not throws. We should not care that > > some called function throws through any more than we care if they > > longjmp though. > > Agreed. > > > Probably it is the case that some pass that has yet to be > > converted to the properly use the new CFG is misinterpreting > > basic block boundaries in the presence of flag_exceptions. > > regmove.c says > > /* ??? We can't scan past the end of a basic block without updating > the register lifetime info (REG_DEAD/basic_block_live_at_start). > A CALL_INSN might be the last insn of a basic block, if it is > inside an EH region. There is no easy way to tell, so we just > always break when we see a CALL_INSN if flag_exceptions is > nonzero. */ > > But as you say, this is unnecessary for code that contains no exception > regions, such as all C code. Considering what should probably happen on pthread_cancel(), which is unwinding both the C cleanup handlers and the C++ stack frames (and possibly catch(...){ }), that tells me that some method of hooking into exception handlers from C needs to be in GCC. I refer to Dave Butenhof's e-mail. This is what happens in the 64-bit UNIX system that he's working on at Compaq (was DEC). It seems to me that the C library, which implements pthreads under Linux, needs to implement deferred cancellation as an exception, with C cleanup handlers using the same mechanism as C++ exception handlers & stack-based object destructors. Does this sound right? -- George T. Talbot From gcc-return-9244-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 18:43:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31493 invoked by alias); 19 Aug 1999 18:43:02 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31430 invoked from network); 19 Aug 1999 18:42:55 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 19 Aug 1999 18:42:55 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA25126; Thu, 19 Aug 1999 11:42:51 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id LAA24137; Thu, 19 Aug 1999 11:42:51 -0700 Date: Thu, 19 Aug 1999 11:42:51 -0700 From: Richard Henderson To: "George T. Talbot" Cc: Jason Merrill , gcc@gcc.gnu.org, libc-alpha@sourceware.cygnus.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Message-ID: <19990819114251.A24132@cygnus.com> References: <37BAD6A5.315C3625@moberg.com> <19990818120050.D26368@cygnus.com> <37BC4F54.F169A2C0@moberg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <37BC4F54.F169A2C0@moberg.com>; from George T. Talbot on Thu, Aug 19, 1999 at 06:39:16PM +0000 On Thu, Aug 19, 1999 at 06:39:16PM +0000, George T. Talbot wrote: > It seems to me that the C library, which implements pthreads under > Linux, needs to implement deferred cancellation as an exception, with C > cleanup handlers using the same mechanism as C++ exception handlers & > stack-based object destructors. That's probably the best way to get the kind of integration that you want. r~ From gcc-return-9245-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 18:47:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1163 invoked by alias); 19 Aug 1999 18:47:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 891 invoked from network); 19 Aug 1999 18:46:52 -0000 Received: from xf86.isc.org (HELO public.xfree86.org) (204.152.184.37) by egcs.cygnus.com with SMTP; 19 Aug 1999 18:46:51 -0000 Received: from localhost (takis@localhost) by public.xfree86.org (8.9.1/8.9.1) with ESMTP id LAA05844 for ; Thu, 19 Aug 1999 11:44:46 -0700 (PDT) Date: Thu, 19 Aug 1999 11:44:46 -0700 (PDT) From: Takis Psarogiannakopoulos To: gcc@gcc.gnu.org Subject: DGUX Unix - GCC-2.95.x Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Folks, I write this e-mail in the list since I tried to contact some folks in Cygnus with no luck. In the release gcc-2.8.1 several developers fix the support for the DG/ux unix (i386). gcc-2.8.1 was officially the first gcc with good support for ix86 DG/ux. Then the egcs project took over gcc, so 2.8.1 was the last (actual) GNU release. gcc-2.95 broke totally all the support for DG/ux. While I understand that you may not have access to a DG/ux machine , I write this e-mail because , besides the compilation errors, you change and the behaviour of cpp. Until the gcc-2.8.1, cpp was a binary in the gcc-local-dir (usually: /usr/local/lib/gcc-lib/host/2.95 or 2.8.1) and not in /usr/local/bin. Nothing however stopping us to copy this single binary to the path. DG/ux unix has a special complicated "elink" mechanism that finally it will divert the /lib/cpp classical Unix preprocessor to ->gcc-local-dir/cpp. This will be also the cpp for the "cc" of the system (than amongst others builds the kernels of the system). However in 2.95 you split cpp to xcpp (gcc.o + some other .o files ,) and the actuall cpp in the gcc-local-dir , only that this second cpp lacks functionality over the previous such (eg 2.8.1). Eg doesnt know cpp_predefines , -undef option etc. This results in that cc breaks and anything that uses cc also (eg the imake command in XFree86) including building correctly the (DGUX) kernels of the system. I took the time these days to make the port of 2.95 to ix86 DG/ux only to discover that it is impossible to run it to DG/ux. The option of copying the external cpp (xcpp) to the gcc-local-dir is out since gcc-local-dir has the actuall cpp which will be overwritten. Also naming the xcpp something else means that we are looking to modify then the elink (OS) mechanism of DG/ux to look for this thing. If you found that the cpp should separate in two modules the correct thing to do will be to name the "internal" cpp in the gcc-local-dir as , say , int_cpp , have gcc and cpp to invoke this binary (so that xcpp=cpp and int_cpp can coexist in the same dir) and have also the xcpp understand _ALL_ the commands that the gcc-2.8.1 cpp knew! At the moment gcc-2.95 is not even installable in ix86 DG/ux. If that was what we do in XFree86 only Linux and FreeBSD will now had Xwindows! Even if we dont have a DG/ux machine we never do such a change, given that in the 2.8.1 was a binary "cpp" that was performing some functionality. So somebody maybe was using this binary for other functionalities (eg ix86 DG/ux). Just eliminating its features in the next release and test it in Linux is not , in my opinion , development of gcc , not at least the one that GNU was pursuing all these years. Please correct this situation and restore cpp in its full features as in 2.8.1. If you feel that an internal module is needed, name it something else (eg int_cpp or whatever) so that can coexist in the gcc-local-dir with the binary of cpp and arrange for cpp gcc to use it accordingly. Regards, T. From gcc-return-9246-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 19:14:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9621 invoked by alias); 19 Aug 1999 19:14:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9574 invoked from network); 19 Aug 1999 19:14:15 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 19 Aug 1999 19:14:15 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id VAA01028; Thu, 19 Aug 1999 21:12:41 +0200 Message-ID: <37BC5729.7A33DA99@moene.indiv.nluug.nl> Date: Thu, 19 Aug 1999 21:12:41 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: Brad Lucier CC: gcc@gcc.gnu.org Subject: Re: sqrt on alphaev6 References: <199908191457.JAA10650@polya.math.purdue.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brad Lucier wrote: > with -mcpu=ev6 -mieee on alphaev6 with gcc 2.95.1 the following code > is typically generated for sqrt: > sqrttsu $f16,$f0 > cmpteqsu $f0,$f0,$f10 ; check for NaN? > fbne $f10,$L836 > jsr $26,sqrt > ldgp $29,0($26) > $L836: > My question is whether the call to the sqrt routines is necessary > for ev6. I find 21264hrm.pdf to be somewhat confusing, but it > seems to imply that software completion is not needed on the 21264. According to the documentation accompanying gcc, one can specify the following macro name for any target architecture (cpu/os combination): `TARGET_EDOM' The value of `EDOM' on the target machine, as a C integer constant expression. If you don't define this macro, GNU CC does not attempt to deposit the value of `EDOM' into `errno' directly. Look in `/usr/include/errno.h' to find the value of `EDOM' on your system. If you do not define `TARGET_EDOM', then compiled code reports domain errors by calling the library function and letting it report the error. If mathematical functions on your system use `matherr' when there is an error, then you should leave `TARGET_EDOM' undefined so that `matherr' is used normally. This constant is not defined for many targets: [toon@moene config]$ grep TARGET_EDOM */*.h arm/linux-aout.h:#define TARGET_EDOM 33 arm/riscix.h:#define TARGET_EDOM 33 sparc/sparc.h:#define TARGET_EDOM 33 HTH, PS: As this has no relevance for other languages than those in the C family, the Fortran Frontend causes this call to sqrt *not* to be generated. -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-9247-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 20:08:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22535 invoked by alias); 19 Aug 1999 20:07:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22492 invoked from network); 19 Aug 1999 20:07:29 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 19 Aug 1999 20:07:29 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA02369; Thu, 19 Aug 1999 13:07:28 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id NAA14797; Thu, 19 Aug 1999 13:07:28 -0700 To: "George T. Talbot" Cc: gcc@gcc.gnu.org Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BAD6A5.315C3625@moberg.com> <37BC5244.3B5E6510@moberg.com> <37BC5B0C.93FDF45F@moberg.com> <37BC612F.C7A2E9A0@moberg.com> From: Jason Merrill Date: 19 Aug 1999 13:07:28 -0700 In-Reply-To: "George T. Talbot"'s message of "Thu, 19 Aug 1999 19:55:27 +0000" Message-ID: Lines: 22 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> George T Talbot writes: > Assuming that I can convince the libc guy(s) to recompile with > -fexceptions, is there a set of functions that I can call to register > and unregister a cleanup handler with the exception mechanism? No; cleanups are registered at compile time in the dwarf2 model. You'll need to extend the C frontend to add the notion of cleanups, like a try ... finally construct, or a cleanup block construct. > If I can do that, then I can rewrite pthread_cleanup_push() and > pthread_cleanup_pop() to work with the exception mechanism and I can > rewrite pthread_cancel() to throw an exception. push and pop would need to be macros. > I'm assuming that even if I compile C code with -fexceptions, that I > still cannot use a "try...catch" block in that C code. Not currently, no. Jason From gcc-return-9248-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 20:08:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22573 invoked by alias); 19 Aug 1999 20:08:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22533 invoked from network); 19 Aug 1999 20:07:47 -0000 Received: from smtprtp1.ntcom.nortel.net (137.118.22.14) by egcs.cygnus.com with SMTP; 19 Aug 1999 20:07:46 -0000 Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Thu, 19 Aug 1999 16:06:29 -0400 Received: from zmtlde5a.ca.nortel.com ([47.64.13.90]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id P2BHC0XD; Thu, 19 Aug 1999 16:05:34 -0400 Received: from wmtl249c.nortel.ca (wmtl249c.ca.nortel.com [47.64.3.156]) by zmtlde5a.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Q064RLAQ; Thu, 19 Aug 1999 16:05:34 -0400 From: "Jerry Quinn" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14268.25483.908195.483130@gargle.gargle.HOWL> Date: Thu, 19 Aug 1999 16:05:31 -0400 (EDT) To: David Edelsohn Cc: veksler@il.ibm.com, egcs@egcs.cygnus.com Subject: Re: Deadly optimization bug (all gcc versions!) In-Reply-To: <9908161641.AA40226@marc.watson.ibm.com> References: <9908161641.AA40226@marc.watson.ibm.com> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) >> "David" == David Edelsohn writes: >>>>>> veksler writes: veksler> The bug shows itself on gcc-2.7.0 gcc-2.7.2.1, egcs-1.0.1, veksler> egcs-1.1.2, gcc-2.95. On AIX-4.1, Linux-x86 (RH4.2 and RH6.0). David> This means that you have seen the bug in both PowerPC and David> IA-32 code generation? I definitely see it in PowerPC. A whole group David> of instructions disappear between flow and combine. Also, -O3 with David> inlining seems to produce correct results. Maybe combine is trying David> some alternate instructions, failing, and then not properly restoring David> the instructions? I just tried this on HPUX 10.20 and get the same behavior. -O gets 0,0,0 and no flags, -g, and -O3 -finline all get 0,1,1 -- Jerry Quinn Tel: (514) 761-8737 jquinn@nortelnetworks.com Fax: (514) 761-8505 Speech Recognition Research From gcc-return-9249-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 20:31:23 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27782 invoked by alias); 19 Aug 1999 20:31:11 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27739 invoked from network); 19 Aug 1999 20:31:05 -0000 Received: from fireserv.molienergy.bc.ca (HELO mailserv.molienergy.bc.ca) (207.216.249.2) by egcs.cygnus.com with SMTP; 19 Aug 1999 20:31:05 -0000 Received: by mailserv.molienergy.bc.ca with Internet Mail Service (5.0.1458.49) id <366V2CHR>; Thu, 19 Aug 1999 13:28:37 -0700 Message-ID: <71B30885B657D111809D080009EEBBF39C9F6E@mailserv.molienergy.bc.ca> From: Jan Reimers To: 'Dean Piper' Cc: "'gcc@gcc.gnu.org'" Subject: RE: configuring C++ download Date: Thu, 19 Aug 1999 13:28:36 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Hello Amy, egcs and gcc must be configured and built in a unix environment which has a working C compiler. Windows 95 does not meet these requirements. You have 3 options: 1) Buy a commercial C/C++ compiler for windows. 2) Download the cygwin system, which gives you a unix shell with the gcc/g++ compilers already installed. see http://sourceware.cygnus.com/cygwin/ for more information. 3) Put the linux operating system on your computer. If your machine has ~500meg of free disk space you can do this without removing Win95. 2 and 3 are free. 3 will give you much better performance and reliability then 2. Hope this helps. JR > ---------- > From: Dean Piper[SMTP:pipercubs@prodigy.net] > Sent: Thursday, August 19, 1999 8:07 AM > To: gcc@gcc.gnu.org > Subject: configuring C++ download > > HELP! I'm can't figure out how your instructions on configuring, > building > and installing the compiler program I downloaded. > > I downloaded the "EGCS 1.1.2 to GCC 2.95 diffs, gzip format, 7.0 meg > > The only zip program my computer has is WINZIP. > > I have windows 95 and Microsoft programs . > > I went into msdos prompt and was able to mkdir objdir.cc and cd > objdir.cc > > I couldn't get any further other than to mkdir srcdir.cc but the > configure > command just won't work in my system. > > I want to be able to write and run C or C++ programs, but I don't know > how > to get this compiler working. Any suggestions will be very > appreciated. > > Amy Piper > pipercubs@prodigy.net > From gcc-return-9250-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 20:34:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29169 invoked by alias); 19 Aug 1999 20:34:42 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29111 invoked from network); 19 Aug 1999 20:34:36 -0000 Received: from tk2.ihug.co.nz (HELO smtp2.ihug.co.nz) (203.29.160.14) by egcs.cygnus.com with SMTP; 19 Aug 1999 20:34:36 -0000 Received: from ihug.co.nz (animal.ihug.co.nz [203.29.161.168]) by smtp2.ihug.co.nz (8.9.3/8.9.3/Debian/GNU) with ESMTP id IAA00574 for ; Fri, 20 Aug 1999 08:34:30 +1200 Message-ID: <37BC6AD5.A0168B80@ihug.co.nz> Date: Fri, 20 Aug 1999 09:36:37 +1300 From: Ross Smith Organization: The Internet Group X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: GCC Mailing List Subject: Re: gcc-2.95.1 References: <2198.935048263@upchuck.cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeffrey A Law wrote: > > + Fix missing std:: in the libstdc++ library. Could you amplify a little on this one, please? I was under the impression that moving libstdc++ fully into namespace std wasn't going to be done before libstdc++ v3 was released. -- Ross Smith The Internet Group, Auckland, New Zealand ======================================================================== The good news, according to the FCC, is that television viewing won't be interrupted by the Y2K problem. The bad news, according to the rest of us, is that television viewing won't be interrupted by the Y2K problem. -- Jonathan Erickson in Dr Dobb's Journal From gcc-return-9251-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 21:11:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3384 invoked by alias); 19 Aug 1999 21:11:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3335 invoked from network); 19 Aug 1999 21:11:24 -0000 Received: from node-cffb924a.powerinter.net (HELO switchmanagement.com) (207.251.146.74) by egcs.cygnus.com with SMTP; 19 Aug 1999 21:11:24 -0000 Received: (qmail 6906 invoked from network); 19 Aug 1999 21:11:23 -0000 Received: from smtp.switchmanagement.com (HELO switchmanagement.com) (207.251.146.74) by smtp.switchmanagement.com with SMTP; 19 Aug 1999 21:11:23 -0000 Message-ID: <37BC72FB.BC216856@switchmanagement.com> Date: Thu, 19 Aug 1999 14:11:23 -0700 From: Brian Strand Organization: Switch Management X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: successfully built gcc-2.95.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit config.guess output: i586-pc-sco3.2v5.0.5 Successfully compiled once with gcc-2.7.{2 or 3, don't remember}, then again with 2.95.1. I had to re-symlink /usr/local/lib/gcc-lib/i586-pc-sco3.2v5.0.5/2.95.1/libstdc++.a to /usr/local/lib/libstdc++.a.2.10.0 using absolute rather than relative paths because the gcc 2.7.x I used (which I got as a SCO binary package from SCO's free software site) installed /usr/local/lib/gcc-lib as a symlink off into /opt/K/... somewhere, so the ..'s in the relative symlink were not going where one would expect. If I didn't do this, g++ complained about not finding libstdc++, which interfered somewhat with compiling C++ programs. Thanks for building such a great compiler (collection)! Brian Strand CTO/Senior Architect/Programmer/Sysadmin/Lead Keyboard Cleaner, Switch Management From gcc-return-9252-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 21:17:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5679 invoked by alias); 19 Aug 1999 21:16:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5640 invoked from network); 19 Aug 1999 21:16:40 -0000 Received: from smtp.interlog.com (root@207.34.202.37) by egcs.cygnus.com with SMTP; 19 Aug 1999 21:16:40 -0000 Received: from crjnt2 (cj.interlog.com [199.212.157.174]) by smtp.interlog.com (8.9.1/8.9.1) with SMTP id RAA28775; Thu, 19 Aug 1999 17:16:23 -0400 (EDT) Message-Id: <3.0.32.19990819171758.009a0c70@mail.interlog.com> X-Sender: cj@mail.interlog.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 19 Aug 1999 17:18:00 -0400 To: Jan Reimers , "'Dean Piper'" From: "Christopher R. Jones" Subject: RE: configuring C++ download Cc: "'gcc@gcc.gnu.org'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" You can use the Win32 version of gcc 2.95. Information and downloads on the following ftp site. ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/ At 01:28 PM 8/19/99 -0700, Jan Reimers wrote: >Hello Amy, > egcs and gcc must be configured and built in a unix environment >which has a working C compiler. Windows 95 does not meet these >requirements. You have 3 options: >1) Buy a commercial C/C++ compiler for windows. >2) Download the cygwin system, which gives you a unix shell with the >gcc/g++ compilers already installed. see >http://sourceware.cygnus.com/cygwin/ for more information. >3) Put the linux operating system on your computer. If your machine has >~500meg of free disk space you can do this without removing Win95. > >2 and 3 are free. 3 will give you much better performance and >reliability then 2. > >Hope this helps. >JR > >> ---------- >> From: Dean Piper[SMTP:pipercubs@prodigy.net] >> Sent: Thursday, August 19, 1999 8:07 AM >> To: gcc@gcc.gnu.org >> Subject: configuring C++ download >> >> HELP! I'm can't figure out how your instructions on configuring, >> building >> and installing the compiler program I downloaded. >> >> I downloaded the "EGCS 1.1.2 to GCC 2.95 diffs, gzip format, 7.0 meg >> >> The only zip program my computer has is WINZIP. >> >> I have windows 95 and Microsoft programs . >> >> I went into msdos prompt and was able to mkdir objdir.cc and cd >> objdir.cc >> >> I couldn't get any further other than to mkdir srcdir.cc but the >> configure >> command just won't work in my system. >> >> I want to be able to write and run C or C++ programs, but I don't know >> how >> to get this compiler working. Any suggestions will be very >> appreciated. >> >> Amy Piper >> pipercubs@prodigy.net >> > > Christopher R. Jones, P.Eng. 14 Oneida Avenue Toronto, Ontario M5J 2E3 Tel. 416 203-7465 Fax. 416 203-3044 Email cj@interlog.com From gcc-return-9253-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 21:49:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12962 invoked by alias); 19 Aug 1999 21:49:07 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12937 invoked from network); 19 Aug 1999 21:49:01 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by egcs.cygnus.com with SMTP; 19 Aug 1999 21:49:01 -0000 Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id RAA13070; Thu, 19 Aug 1999 17:48:52 -0400 Received: from marc.watson.ibm.com (marc.watson.ibm.com [9.2.176.11]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id RAA13710; Thu, 19 Aug 1999 17:48:51 -0400 Received: from localhost by marc.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA30384; Thu, 19 Aug 1999 17:48:51 -0400 Message-Id: <9908192148.AA30384@marc.watson.ibm.com> To: Takis Psarogiannakopoulos Cc: gcc@gcc.gnu.org Subject: Re: DGUX Unix - GCC-2.95.x Reply-To: gcc@gcc.gnu.org In-Reply-To: Message from Takis Psarogiannakopoulos of "Thu, 19 Aug 1999 11:44:46 PDT." Date: Thu, 19 Aug 1999 17:48:51 -0400 From: David Edelsohn GCC-2.95 has incorporated most all of the development in gcc-2.8.1 and beyond. The last remaining pieces will be incorporated soon. All DG/ux changes would have been merged into EGCS. GCC-2.95 runs well on many other platforms besides Linux, so gcc-2.95 did not gratuituously break cpp on DG/ux or other non-Linux platforms. I am very confused by much of your message. xcpp is installed in cpp_install_dir only if that Makefile variable is defined. Does DG/ux requires that $(prefix)/bin/cpp exist and needs to have identical behavior to gcc_local_dir? As always, the GCC maintainers welcome greater participation in regression testing and patches to improve functionality of GCC on various platforms. If some gcc-2.8.1 functionality on DG/ux did not get merged correctly or DG/ux requires special configuration options, the maintainers would be glad to consider patches to fix these problems. David From gcc-return-9254-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 19 22:46:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26088 invoked by alias); 19 Aug 1999 22:46:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26068 invoked from network); 19 Aug 1999 22:46:31 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 19 Aug 1999 22:46:31 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA14123; Thu, 19 Aug 1999 15:46:30 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id PAA15614; Thu, 19 Aug 1999 15:46:30 -0700 To: "George T. Talbot" Cc: gcc@gcc.gnu.org Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BAD6A5.315C3625@moberg.com> <37BC5244.3B5E6510@moberg.com> <37BC5B0C.93FDF45F@moberg.com> <37BC612F.C7A2E9A0@moberg.com> <37BC7C90.4A40750F@moberg.com> From: Jason Merrill Date: 19 Aug 1999 15:46:30 -0700 In-Reply-To: "George T. Talbot"'s message of "Thu, 19 Aug 1999 21:52:16 +0000" Message-ID: Lines: 31 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> George T Talbot writes: > Jason Merrill wrote: >> >> No; cleanups are registered at compile time in the dwarf2 model. You'll >> need to extend the C frontend to add the notion of cleanups, like a try >> ... finally construct, or a cleanup block construct. > Ugh. This is starting to get beyond my skill level. I can do the C > library stuff, but I'm not sure I understand how to extend the compiler > this way. Actually, the simplest approach would be to make them builtin functions, __builtin_cleanup_push (routine, arg) and __builtin_cleanup_pop (execute). You would call expand_eh_region_start_tree in stmt.c to register the cleanup, and if execute is true when popping, extract the cleanup info from the ehstack and run it directly. It would be hard to map the existing API onto try ... finally. >> > If I can do that, then I can rewrite pthread_cleanup_push() and >> > pthread_cleanup_pop() to work with the exception mechanism and I can >> > rewrite pthread_cancel() to throw an exception. >> >> push and pop would need to be macros. > Yup. They are now, if you look at pthreads.h. And I see that they are required to be symmetrical, at the same nesting level. Good; this is crucial for the compile-time approach to work. Jason From gcc-return-9255-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 01:48:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29464 invoked by alias); 20 Aug 1999 01:48:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29443 invoked from network); 20 Aug 1999 01:48:33 -0000 Received: from rtl.cygnus.com (HELO gluttony.geoffk.wattle.id.au) (205.180.230.21) by egcs.cygnus.com with SMTP; 20 Aug 1999 01:48:33 -0000 Received: (from geoffk@localhost) by gluttony.geoffk.wattle.id.au (8.9.3/8.9.3) id LAA00713; Fri, 20 Aug 1999 11:08:56 +1000 To: Toon Moene CC: gcc@gcc.gnu.org Subject: Re: sqrt on alphaev6 References: <199908191457.JAA10650@polya.math.purdue.edu> <37BC5729.7A33DA99@moene.indiv.nluug.nl> From: Geoff Keating Date: 20 Aug 1999 11:08:55 +1000 In-Reply-To: Toon Moene's message of "Thu, 19 Aug 1999 21:12:41 +0200" Message-ID: Lines: 28 X-Mailer: Gnus v5.5/Emacs 20.3 Toon Moene writes: > Brad Lucier wrote: > > My question is whether the call to the sqrt routines is necessary > > for ev6. I find 21264hrm.pdf to be somewhat confusing, but it > > seems to imply that software completion is not needed on the 21264. > > According to the documentation accompanying gcc, one can specify the > following macro name for any target architecture (cpu/os combination): > > `TARGET_EDOM' > The value of `EDOM' on the target machine, as a C integer constant > expression. If you don't define this macro, GNU CC does not > attempt to deposit the value of `EDOM' into `errno' directly. > Look in `/usr/include/errno.h' to find the value of `EDOM' on your > system. ... > This constant is not defined for many targets: ... On most targets (certainly all linux, for instance), you can't do this because the math error handling is more complicated than just setting errno. SVR4-derived code expects an application function called 'matherr' to be called, for instance (yuk!). -- Geoffrey Keating From gcc-return-9256-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 02:51:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7297 invoked by alias); 20 Aug 1999 02:51:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7225 invoked from network); 20 Aug 1999 02:51:06 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 20 Aug 1999 02:51:06 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id RAA04801; Thu, 19 Aug 1999 17:08:52 -0600 To: Ross Smith cc: GCC Mailing List Subject: Re: gcc-2.95.1 Reply-To: law@cygnus.com In-reply-to: Your message of Fri, 20 Aug 1999 09:36:37 +1300. <37BC6AD5.A0168B80@ihug.co.nz> Date: Thu, 19 Aug 1999 17:08:52 -0600 Message-ID: <4798.935104132@upchuck.cygnus.com> From: Jeffrey A Law In message <37BC6AD5.A0168B80@ihug.co.nz>you write: > Jeffrey A Law wrote: > > > > + Fix missing std:: in the libstdc++ library. > > Could you amplify a little on this one, please? I was under the > impression that moving libstdc++ fully into namespace std wasn't going > to be done before libstdc++ v3 was released. Read the diffs. I'm not a C++ hacker. It was requested by the C++ folks to include that patch in gcc-2.95. jeff From gcc-return-9257-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 02:52:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8443 invoked by alias); 20 Aug 1999 02:52:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8414 invoked from network); 20 Aug 1999 02:52:54 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 20 Aug 1999 02:52:54 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id RAA04911; Thu, 19 Aug 1999 17:18:40 -0600 To: obrien@NUXI.com cc: gcc@gcc.gnu.org Subject: Re: DBX directives Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 18 Aug 1999 23:04:52 PDT. <19990818230452.B64369@dragon.nuxi.com> Date: Thu, 19 Aug 1999 17:18:40 -0600 Message-ID: <4908.935104720@upchuck.cygnus.com> From: Jeffrey A Law In message <19990818230452.B64369@dragon.nuxi.com>you write: > Right now the tm.h list is: alpha/alpha.h svr4.h alpha/freebsd.h > (svr4.h is there because it was in the FreeBSD/i386 case) > > svr4.h defines just about all the *_DEBUGGING_INFO macros. It seems that > many ELF platform includes svr4.h for ELF definitions. Should svr4.h be > defining so much about the environment? > > Or should I move away from svr4.h, moving maybe 1/2 of its contents into > freebsd.h? Use svr4.h and define PREFERRED_DEBUGGING_TYPE. Or maybe you should read the documentation, which will tell you that if your port defines multiple debug formats that you have to define PREFERRED_DEBUGGING_TYPE. jeff From gcc-return-9258-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 02:54:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9451 invoked by alias); 20 Aug 1999 02:54:24 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9415 invoked from network); 20 Aug 1999 02:54:22 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 20 Aug 1999 02:54:22 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id RAA04829; Thu, 19 Aug 1999 17:14:24 -0600 To: Takis Psarogiannakopoulos cc: gcc@gcc.gnu.org Subject: Re: DGUX Unix - GCC-2.95.x Reply-To: law@cygnus.com In-reply-to: Your message of Thu, 19 Aug 1999 11:44:46 PDT. Date: Thu, 19 Aug 1999 17:14:24 -0600 Message-ID: <4826.935104464@upchuck.cygnus.com> From: Jeffrey A Law In message you wr ite: > Dear Folks, > I write this e-mail in the list since I tried to > contact some folks in Cygnus with no luck. Probably because your mail was so disjointed and unreadable that nobody wanted to bother to try and understand it. > gcc-2.95 broke totally all the support for DG/ux. Certainly not on purpose. And I would *strongly* disagree that gcc-2.8.1 actually worked correctly on dgux. The dgux port is a complete and total mess. I considered trying to get the various fixes into gcc-2.95, but there were many things which were more important than the dgux port. > errors, you change and the behaviour of cpp. To be ansi compliant. > single binary to the path. DG/ux unix has a special complicated > "elink" mechanism that finally it will divert the /lib/cpp > classical Unix preprocessor to ->gcc-local-dir/cpp. You should never, ever, ever call the hidden version of cpp. Doing so is wrong and dumb and will ultimiately cause you problems. > such (eg 2.8.1). Eg doesnt know cpp_predefines , -undef option > etc. This results in that cc breaks and anything that uses cc also > (eg the imake command in XFree86) including building correctly the > (DGUX) kernels of the system. imake should not depend on -Di386, it is an ANSI violation for the compiler to define -Di386. jeff From gcc-return-9259-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 03:21:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15206 invoked by alias); 20 Aug 1999 03:21:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15191 invoked from network); 20 Aug 1999 03:21:06 -0000 Received: from nuxi.cs.ucdavis.edu (HELO relay.nuxi.com) (@169.237.7.38) by egcs.cygnus.com with SMTP; 20 Aug 1999 03:21:06 -0000 Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id UAA56709; Thu, 19 Aug 1999 20:21:01 -0700 (PDT) (envelope-from obrien) Message-ID: <19990819202101.A56618@nuxi.com> Date: Thu, 19 Aug 1999 20:21:01 -0700 From: "David O'Brien" To: law@cygnus.com Cc: gcc@gcc.gnu.org Subject: Re: DBX directives Reply-To: obrien@NUXI.com References: <19990818230452.B64369@dragon.nuxi.com> <4908.935104720@upchuck.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <4908.935104720@upchuck.cygnus.com>; from Jeffrey A Law on Thu, Aug 19, 1999 at 05:18:40PM -0600 X-Operating-System: FreeBSD 3.2-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 > > Or should I move away from svr4.h, moving maybe 1/2 of its contents into > > freebsd.h? > Use svr4.h and define PREFERRED_DEBUGGING_TYPE. > > Or maybe you should read the documentation, which will tell you that if > your port defines multiple debug formats that you have to define > PREFERRED_DEBUGGING_TYPE. I *DID* read the documentation. And if you go look at various configuration files they are all over the place on their use. I am trying to clean up the freebsd headers so they will be acceptable to you. We will be submitting configuration headers for FreeBSD/Alpha. So it would be really nice if things were straighted out before the Alpha support gets submitted. Please point me to just one clean multi-arch example. gcc-2.95/gcc/config/ is a mess. I've heard of a post-2.95 cleanup, but I haven't seen any description of what the style will be post-cleanup. Point me at the documentation. (1) svr4.h defines suport for DWARF_DEBUGGING_INFO, DWARF2_DEBUGGING_INFO, DBX_DEBUGGING_INFO. My ports DOESN'T need all that svr4.h gives me. (2) svr4.h has: #ifndef PREFERRED_DEBUGGING_TYPE #define PREFERRED_DEBUGGING_TYPE DWARF_DEBUG #endif Thus I must #undef it in freebsd-elf.h, since we have tm.h do the include for us. Ie., I can't "#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG" and then "#include ". (or should that be "svr4.h"??? existing configurations have both) I can't have tm.h include i386/freebsd-elf.h first, because I have to override many things set in svr4.h. Since I have to override much of svr4.h (and no ELF-based BSD includes svr4.h), THAT is why I asked if maybe I shouldn't be including it in the first place. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) From gcc-return-9260-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 04:06:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21166 invoked by alias); 20 Aug 1999 04:06:31 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21141 invoked from network); 20 Aug 1999 04:06:30 -0000 Received: from q4.quik.com (216.176.28.1) by egcs.cygnus.com with SMTP; 20 Aug 1999 04:06:30 -0000 Received: from ip243.dupage1.quik.com (ip243.dupage1.quik.com [209.213.155.243]) by q4.quik.com (8.9.3/8.9.3) with ESMTP id VAA133078; Thu, 19 Aug 1999 21:06:26 -0700 Date: Thu, 19 Aug 1999 23:06:20 -0500 (CDT) From: Juha Korpela X-Sender: jkorpela@lutikka.korpela.org To: hpux@gatekeep.cs.utah.edu cc: gcc@gcc.gnu.org Subject: gcc problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have uname -a HP-UX lutikka B.10.30 A 9000/712 2002399864 two-user license lutikka ~> which gcc /opt/gcc/bin/gcc lutikka ~> gcc --version 2.8.1 lutikka /tmp/jkorpela/z/disk/hello> which as /opt/binutils/bin/as lutikka /tmp/jkorpela/z/disk/hello> as --version GNU assembler 2.9.1 Copyright 1997 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `hppa1.1-hp-hpux10.20'. I try to compile lutikka /tmp/jkorpela/z/disk/hello> cat hello.cc #include int main() { cout << "Hello World\n"; return (0); } I get lutikka /tmp/jkorpela/z/disk/hello> gcc -o hello hello.cc as: "/tmp/jkorpela/cca02278.s", line 101: error 1052: Directive name not recognized - NSUBSPA What is this "Directive name not recognized - NSUBSPA" error? How to fix it? Also, is g++ the same as gcc? I did not find this script wrapper from HPUX archieve. Regards, Juha Korpela Carnegie Mellon University From gcc-return-9261-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 07:01:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4554 invoked by alias); 20 Aug 1999 07:01:14 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4530 invoked from network); 20 Aug 1999 07:01:08 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 20 Aug 1999 07:01:08 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id AAA05916; Fri, 20 Aug 1999 00:59:47 -0600 X-Mailer: exmh version 2.0.2 To: Juha Korpela cc: hpux@gatekeep.cs.utah.edu, gcc@gcc.gnu.org Subject: Re: gcc problem Reply-To: law@cygnus.com In-reply-to: Your message of Thu, 19 Aug 1999 23:06:20 CDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Aug 1999 00:59:47 -0600 Message-ID: <5913.935132387@upchuck.cygnus.com> From: Jeffrey A Law In message you w > lutikka /tmp/jkorpela/z/disk/hello> gcc -o hello hello.cc > as: "/tmp/jkorpela/cca02278.s", line 101: error 1052: Directive name not > recognized - NSUBSPA > > What is this "Directive name not recognized - NSUBSPA" error? How to fix > it? GCC is finding the HP assembler before the GNU assembler. Please see the GCC FAQ. It covers this issue explicitly. jeff From gcc-return-9262-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 07:28:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8416 invoked by alias); 20 Aug 1999 07:28:31 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8400 invoked from network); 20 Aug 1999 07:28:27 -0000 Received: from unknown (HELO stargate.astr.lu.lv) (195.13.132.244) by egcs.cygnus.com with SMTP; 20 Aug 1999 07:28:27 -0000 Received: from hal (unverified [195.13.134.67]) by stargate.astr.lu.lv (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 20 Aug 1999 10:28:24 +0300 From: Andris Pavenis Organization: AI LU To: "Dean Piper" , Subject: Re: configuring C++ download Date: Fri, 20 Aug 1999 10:26:31 +0000 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain References: <199908191504.LAA711186@pimout2-int.prodigy.net> MIME-Version: 1.0 Message-Id: <99082010281900.00153@hal> Content-Transfer-Encoding: 8bit On Thu, 19 Aug 1999, Dean Piper wrote: > HELP! I'm can't figure out how your instructions on configuring, building > and installing the compiler program I downloaded. > > I downloaded the "EGCS 1.1.2 to GCC 2.95 diffs, gzip format, 7.0 meg > > The only zip program my computer has is WINZIP. > > I have windows 95 and Microsoft programs . > > I went into msdos prompt and was able to mkdir objdir.cc and cd objdir.cc > > I couldn't get any further other than to mkdir srcdir.cc but the configure > command just won't work in my system. > > I want to be able to write and run C or C++ programs, but I don't know how > to get this compiler working. Any suggestions will be very appreciated. > You may also try DJGPP http://www.delorie.com/djgpp/ It's not Win32 (but DOS) but works Ok with Win95 (also with long filename) Andris From gcc-return-9263-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 07:30:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9267 invoked by alias); 20 Aug 1999 07:30:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9252 invoked from network); 20 Aug 1999 07:30:17 -0000 Received: from xf86.isc.org (HELO public.xfree86.org) (204.152.184.37) by egcs.cygnus.com with SMTP; 20 Aug 1999 07:30:17 -0000 Received: from localhost (takis@localhost) by public.xfree86.org (8.9.1/8.9.1) with ESMTP id AAA03712; Fri, 20 Aug 1999 00:28:03 -0700 (PDT) Date: Fri, 20 Aug 1999 00:28:01 -0700 (PDT) From: Takis Psarogiannakopoulos To: Jeffrey A Law cc: gcc@gcc.gnu.org Subject: RE:DGUX Unix - GCC-2.95.x Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, On Thu, 19 Aug 1999, Jeffrey A Law wrote: > In message you $> ite: > Probably because your mail was so disjointed and unreadable that nobody > wanted to bother to try and understand it. > OK. I am sorry for this I did wrote it in a rush. > Certainly not on purpose. OK. > And I would *strongly* disagree that > gcc-2.8.1 actually worked correctly on dgux. The dgux port is a > complete and total mess. I considered trying to get the various fixes > into gcc-2.95, but there were many things which were more important than > the dgux port. > How many DG/ux machines do you have in cygnus? I have done also the gdb port, and I've been told that you dont have any DG/ux machines. gcc-2.8.1 works in DG/ux ix86. Perhaps needs one-two more changes than the one in GNU but after that it performs well. I am compiling X11R6, All the GNU toolkit , KDE, and whatever. More than 600 MBs binaries. Dont confuse the problems of gcc-2.8.1 to work in coordination with the DG/ux as and produce dwarf-2 with the general functionality of gcc. Only recently I found that QT-2.0.1 doesnt compile correctly with gcc-2.8.1 (c++) That is the only real serious bug that I am aware. Disassembling the .s files reveals the fix though. > To be ansi compliant. OK. My problem is not that since the external cpp (xcpp) works ok. (has almost all the features that I need). Only I cannot copy it in the gcc-local-dir since it will overwrite the "hidden version of cpp" Typically in DG/ux we make a dir , say gcc-dg-2.95, with all the files of gcc inside ie, gcc,c++,g++, libgcc,libobjc, cc1, cc1plus, cc1obj, specs, cpp, crt* files , and we copy this directory to the elink. Then the DG/ux elink will arrange to point from there the tools to the actual "user path". What I am saying is that in gcc.2.8.1 there was only _one_ "hidden" cpp , that was living inside there. So if you now introducing a change it will be good to leave this feature alone and just make a "hidden_cpp" (or what ever other name you want) in gcc-local-dir. If for some reason DG has arrange to access this cpp through its elink the correct thing for the developer is not to change it and then say to DGux users to contact DG (EMC) to change this particular feature... > imake should not depend on -Di386, it is an ANSI violation for > the compiler to define -Di386. > ???... imake compiles with DGUX native cc. DG/UX cc will invoke cpp in the gcc-local-dir (in more detail: the /lib/cpp that points through the elink mechanism to an executable named cpp in the gcc-local-dir). As the "hidden" 2.95 cpp misses features, cc will halt with errors. If we had the sources of DG/ux we would be able of course to modify the elink binaries in /usr/opt/sdk/bin to invoke the tools of our choice. But I guess we dont have this option ... Regards, T. From gcc-return-9264-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 07:55:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12971 invoked by alias); 20 Aug 1999 07:55: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12954 invoked from network); 20 Aug 1999 07:55:20 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 20 Aug 1999 07:55:20 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id AAA00480; Fri, 20 Aug 1999 00:47:54 -0700 Message-Id: <199908200747.AAA00480@zack.bitmover.com> To: Takis Psarogiannakopoulos cc: Jeffrey A Law , gcc@gcc.gnu.org Subject: Re: DGUX Unix - GCC-2.95.x In-Reply-To: Message from Takis Psarogiannakopoulos of "Fri, 20 Aug 1999 00:28:01 PDT." Date: Fri, 20 Aug 1999 00:47:54 -0700 From: Zack Weinberg Takis Psarogiannakopoulos wrote: > > To be ansi compliant. > > OK. My problem is not that since the external cpp (xcpp) works ok. > (has almost all the features that I need). Only I cannot copy it in > the gcc-local-dir since it will overwrite the "hidden version of cpp" > Typically in DG/ux we make a dir , say gcc-dg-2.95, with all the files > of gcc inside ie, gcc,c++,g++, libgcc,libobjc, cc1, cc1plus, cc1obj, > specs, cpp, crt* files , and we copy this directory to the elink. > Then the DG/ux elink will arrange to point from there the tools > to the actual "user path". What you should be doing is setting --prefix to this gcc-dg-2.95 directory when you configure gcc. You'll then get a directory tree under that directory. Make the executables in gcc-dg-2.95/bin, and *ONLY* those executables, known to elink. Do not otherwise rearrange the tree. The other files - the ones that will appear in gcc-dg-2.95/lib/gcc-lib/i386-dg-dguxN/2.95/ - are never to be referenced by users. elink should not be aware of them, they should not appear in $PATH, etc. What are the missing features of the "external cpp" as you call it? zw From gcc-return-9265-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 07:56:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13778 invoked by alias); 20 Aug 1999 07:56:46 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13723 invoked from network); 20 Aug 1999 07:56:40 -0000 Received: from xf86.isc.org (HELO public.xfree86.org) (204.152.184.37) by egcs.cygnus.com with SMTP; 20 Aug 1999 07:56:40 -0000 Received: from localhost (takis@localhost) by public.xfree86.org (8.9.1/8.9.1) with ESMTP id AAA10145; Fri, 20 Aug 1999 00:54:36 -0700 (PDT) Date: Fri, 20 Aug 1999 00:54:36 -0700 (PDT) From: Takis Psarogiannakopoulos To: gcc@gcc.gnu.org cc: David Edelsohn Subject: RE: DGUX Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Perhaps this gives a better understanding of the DGUX elink gcc. ------------------------------------------------ David, I just send a message to the list. The story for the elink of DG/ux is as follows : (2.8.1) A) we collect all gcc files , ie. c++, g++,gcc, protoize,unprotoize,gcov, cpp, libgcc.a, libobjc.a, specs, and the several crt* files to a single dir say gcc-dgux-281. B) copy this dir to /usr/sde/ix86dgux/usr/lib C) make a link in /usr/sde/ix86dgux/usr/lib gcc->gcc-dgux-281. Our new gcc is active. /lib/cpp (the tratitional Unix preprocessor) will point to a binary called cpp lying in gcc-dgux-281). DGUX native cc, if it wants to compile something , it will invoke the binary elink/cpp aka a binary lying in gcc-dgux-281 under the name cpp. As in 2.8.1 there is exactly one binary named cpp it can go inside gcc-dgux-281. In 2.95 there are 2 the /usr/local/bin/cpp (xcpp) and the cpp. Even if we dont install xcpp the hidden cpp is a "semicpp"! eg :it doesnt know -undef option. If we copy them in the same dir under the name cpp one will overwrite the other. Regards, T. From gcc-return-9266-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 08:37:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19302 invoked by alias); 20 Aug 1999 08:37:39 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19287 invoked from network); 20 Aug 1999 08:37:36 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 20 Aug 1999 08:37:36 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id KAA10953; Fri, 20 Aug 1999 10:37:24 +0200 (MET DST) Date: Fri, 20 Aug 1999 10:37:23 +0200 (MET DST) From: Gerald Pfeifer To: GCC mailing list cc: Marc Lehmann Subject: Re: pgcc status? In-Reply-To: <19990818115424.C26368@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 18 Aug 1999, Richard Henderson wrote: > On Wed, Aug 18, 1999 at 04:50:25PM +0100, Rask Ingemann Lambertsen wrote: >> The dnsserver returned: >> DNS Domain 'www.gcc.ml.org' is invalid: Host not found (authoritative). > It was certainly just a transient error -- > > Server: cygnus.com > Address: 205.180.230.20 > > Non-authoritative answer: > Name: goof.com > Address: 12.4.218.41 > Aliases: www.gcc.ml.org, www.goof.com FYI: I contacted Marc Lehmann and he told me that ml.org has been abandoned, thus also name service for www.gcc.ml.org. Interestingly some name servers like ours or the one of cygnus still have (cached?) the old address, but in any case Marc has updated the link on the egcstensions.html page, so that it should now work for all of us. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9267-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 09:06:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23594 invoked by alias); 20 Aug 1999 09:05:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23572 invoked from network); 20 Aug 1999 09:05:50 -0000 Received: from fw-ext.ascend.com (198.4.92.5) by egcs.cygnus.com with SMTP; 20 Aug 1999 09:05:50 -0000 Received: from tucson-net-86.eng.ascend.com by fw-ext.ascend.com via smtpd (for egcs.cygnus.com [205.180.83.80]) with SMTP; 20 Aug 1999 09:05:50 UT Received: (from gkm@localhost) by tucson-net-82.eng.ascend.com (8.8.7/8.8.7) id XAA31173; Thu, 19 Aug 1999 23:05:10 -1000 Date: Thu, 19 Aug 1999 23:05:10 -1000 Message-Id: <199908200905.XAA31173@tucson-net-82.eng.ascend.com> X-Authentication-Warning: tucson-net-82.eng.ascend.com: gkm set sender to gkm@eng.ascend.com using -f From: Greg McGary To: gcc@gcc.gnu.org Subject: MIPS and the frame pointer (non)chain Lack of a frame pointer chain on MIPS makes it somewhat painful to trace the stack at runtime. Symbolic debuggers with access to a complete symbol table can get by, but embedded runtime environments without reliable ways to find function boundaries have more trouble. I experimented with `-fno-omit-frame-pointer' hoping this would persuade gcc to thread a frame pointer chain into the stack. Unfortunately, it didn't help, because the frame links aren't stored at a fixed offset in the frame. Is there any *good* reason why gcc shouldn't save $fp and $ra at a fixed offset from the current frame pointer? $fp+(4*gp-reg-size) and $fp+(5*gp-reg-size) are the natural choices, leaving 4*gp-reg-size immediately after $fp for the argument build area. Yes, there is a pedantic reason, but IMO it's not a *good* one: the MIPS ABI (SysV ABI MIPS supplement 3ed) states on page 3-15 that "Registers are saved in numerical order, with higher numbered registers saved in higher memory addresses". Furthermore, figure 3-21 on page 3-16 shows that the floating-point register save area resides at lower address than the general register save area. In order for the saved $fp and $ra to be at fixed offset from the current $fp, the saved GP regs must trade places with the saved FP regs. With this change, `-fno-omit-frame-pointer' would give a useable frame-pointer chain so tracing the stack would require no decoding of function prologues and would be as simple as it is on Motorola CPUs. Is there any reason, in principle, why this change wouldn't be acceptable for gcc? If not acceptable as default behavior, how about as optional behavior? If it's OK in principle, I'll go ahead and implement it. If not, I guess I'll work on the runtime stack tracer. 8^) Greg From gcc-return-9268-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 10:33:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2886 invoked by alias); 20 Aug 1999 10:32:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2866 invoked from network); 20 Aug 1999 10:32:39 -0000 Received: from iron.singnet.com.sg (165.21.7.29) by egcs.cygnus.com with SMTP; 20 Aug 1999 10:32:38 -0000 Received: from 145.35.0.30 (qtas0102.singnet.com.sg [165.21.56.12]) by iron.singnet.com.sg (8.9.1a/8.9.1) with SMTP id SAA21303 for ; Fri, 20 Aug 1999 18:32:35 +0800 (SGT) Message-ID: <37BD2C7D.1D80@singnet.com.sg> Date: Fri, 20 Aug 1999 18:22:53 +0800 From: Rob Kramer Organization: InfoLogic Pte Ltd X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: egcs@egcs.cygnus.com Subject: SCO 5.0.2 signal 11 + exceptions problem.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi there, (hi Robert :) I tried building GCC 2.95 for SCO OSR v3.2 5.0.2, and got a 'fatal signal 11 in as' somewhere along the build (while compiling 'exception.c'). This signal seems to occur at each of my attempts to build gcc. ----------------- make[5]: Leaving directory `/usr/rob/gnu/gcc-obj/gcc' make[5]: Entering directory `/usr/rob/gnu/gcc-obj/gcc' ./xgcc -B./ -B/usr/local/gcc-2.95/i586-pc-sco3.2v5.0.0/bin/ -I/usr/local/gcc- 2.95/i586-pc-sco3.2v5.0.0/include -O2 -DIN_GCC -O2 -O -I./include - g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -g -O2 -I. - I../../gcc-2.95/gcc -I../../gcc-2.95/gcc/config -I../../gcc-2.95/gcc/../include \ -c -fexceptions ../../gcc-2.95/gcc/cp/exception.cc xgcc: Internal compiler error: program as got fatal signal 11 ----------------- If I restart make, it seems to build just fine. But when trying to compile a 'hello world' program, I get the following: ----------------- [ildev2] /usr/rob/c++> /usr/local/gcc-2.95/bin/g++ -fexceptions test.cc Undefined first referenced symbol in file exception virtual table /usr/local/gcc-2.95/lib/gcc-lib/i586-pc- sco3.2v5.0.0/2.95/libgcc.a(opnew.o) __check_eh_spec /usr/local/gcc-2.95/lib/gcc-lib/i586-pc- sco3.2v5.0.0/2.95/libgcc.a(opdel.o) __eh_alloc /usr/local/gcc-2.95/lib/gcc-lib/i586-pc- sco3.2v5.0.0/2.95/libgcc.a(opnew.o) exception::what(void) const /usr/local/gcc-2.95/lib/gcc-lib/i586-pc- sco3.2v5.0.0/2.95/libgcc.a(tinfo.o) __cp_pop_exception /usr/local/gcc-2.95/lib/gcc-lib/i586-pc- sco3.2v5.0.0/2.95/libgcc.a(opdel.o) exception type_info node /usr/local/gcc-2.95/lib/gcc-lib/i586-pc- sco3.2v5.0.0/2.95/libgcc.a(tinfo.o) terminate(void) /usr/tmp/ccjLebPI.o __start_cp_handler /usr/local/gcc-2.95/lib/gcc-lib/i586-pc- sco3.2v5.0.0/2.95/libgcc.a(opdel.o) exception type_info function /usr/local/gcc-2.95/lib/gcc-lib/i586-pc- sco3.2v5.0.0/2.95/libgcc.a(tinfo.o) __cp_push_exception /usr/local/gcc-2.95/lib/gcc-lib/i586-pc- sco3.2v5.0.0/2.95/libgcc.a(opnew.o) a.out: fatal error: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status ----------------- Sigh. This looks like my build is broken because of the signal 11 in exception.c? I'm using egcs 1.1.1 incapable of RTTI to bootstrap. Should it have RTTI? (couldn't get egcs 1.1.1 to compile otherwise.) I believe exceptions need RTTI to work, but I don't need exceptions to bootstrap, or do I? How to get rid of signal 11? (what *is* signal 11) Wonder if GNU as would get that signal too.. Thanks! Rob Kramer robk@cyberway.com.sg From gcc-return-9269-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 11:04:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5152 invoked by alias); 20 Aug 1999 11:04:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5136 invoked from network); 20 Aug 1999 11:04:52 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 20 Aug 1999 11:04:52 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id NAA18401; Fri, 20 Aug 1999 13:02:09 +0200 (MET DST) Date: Fri, 20 Aug 1999 13:02:08 +0200 (MET DST) From: Gerald Pfeifer To: Igor Markov cc: Joe Buck , steveo@world.std.com, john@feith.com, gcc@egcs.cygnus.com Subject: Re: a more constructive discussion ;-) In-Reply-To: <37A9DD04.47C19B1E@cs.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 5 Aug 1999, Igor Markov wrote: > interestingly, my suggestion does not conflict with this at all. > Given the feedback that I got from this list so far, I would boil > it to the following: > > 1) create a mailing list "gcc-binaries" > 2) maintain a page with "binary distributions" > 3) maintain "binary packaging test status" on a separate page, > i.e., a list of reported successful/failed installation > on various systems; > 4) keep a list of volunteer "contacts" for various platforms > who are willing to assume some limited responsibily and > take care of bug reports > [...] > If that sounds good, I would be willing to contribute some of my time > to this activity. > > comments? Most/all of us have rather long queues of GCC work these days, for example, right now one port (FreeBSD) does not even bootstrap because none has had sufficient time to review a patch that fixes the problem. However, if you are going to set up a web page/mailing list covering that information, I will be happy to provide a link from our site. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9270-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 15:00:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6536 invoked by alias); 20 Aug 1999 15:00:09 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6521 invoked from network); 20 Aug 1999 15:00:07 -0000 Received: from nenuphar.saclay.cea.fr (132.166.192.7) by egcs.cygnus.com with SMTP; 20 Aug 1999 15:00:07 -0000 Received: from muguet.saclay.cea.fr (muguet.saclay.cea.fr [132.166.192.6]) by nenuphar.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.0.D20) with ESMTP id RAA13032 for ; Fri, 20 Aug 1999 17:00:05 +0200 (MET DST) Received: from pendragon-int.shfj.cea.fr (pendragon.shfj.cea.fr [132.166.81.1]) by muguet.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.1.D20) with SMTP id RAA01843 for ; Fri, 20 Aug 1999 17:00:05 +0200 (MET DST) Received: by pendragon-int.shfj.cea.fr; id QAA25948; Fri, 20 Aug 1999 16:53:57 +0200 Received: from uriens.shfj.cea.fr(193.48.23.6) by pendragon-int.shfj.cea.fr via smap (3.2) id xma025936; Fri, 20 Aug 99 16:53:28 +0200 Received: from orcanie.shfj.cea.fr by shfj.cea.fr (8.6.10/PROTO-CEANET-3.0) with ESMTP id QAA03845 for ; Fri, 20 Aug 1999 16:58:52 +0200 Received: from shfj.cea.fr (localhost [127.0.0.1]) by orcanie.shfj.cea.fr (8.9.1b+Sun/8.9.1) with ESMTP id QAA02562 for ; Fri, 20 Aug 1999 16:59:49 +0200 (MET DST) Message-ID: <37BD6D64.A895D1B0@shfj.cea.fr> Date: Fri, 20 Aug 1999 16:59:48 +0200 From: Dimitri Papadopoulos Organization: SHFJ X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: French/France, fr-FR, Greek, en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: GCC 2.95.1 'make bootstrap' oddities on Solaris Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I am trying to 'make bootstrap' GCC 2.95.1 on Solaris 7. I got some segfaults during build, but finally managed to build GCC. I would appreciate some insight on what did happen. The initial situation is as follows: - The previously installed compiler is egcs-1.1.2. - /usr/ucb is not in the PATH and /usr/ccs/bin contains Sun's as and ld with the latest patches available (107058-01 for as). - The egcs-1.1.2 compiler may use GNU as and GNU ld from binutils-2.9.1. This is achieved following the FAQ instructions: cd /lib/gcc-lib/sparc-sun-solaris2.7/egcs-2.91.66 ln -s /bin/as ln -s /bin/ld Then I try to build GCC 2.95.1. Here are 3 different scenarios: 1) - egcs-1.1.2 uses GNU as and ld following the FAQ instructions - directory /usr/ccs/bin is in the PATH, so Sun as and ld are available I get a segfault: $ ./configure --enable-shared $ make bootstrap [...] stage1/xgcc -Bstage1/ -B/pub_dom/gcc-2.95.1/sparc-sun-solaris2.7/bin/ -DIN_GCC -DHAIFA -DSVR4 -O2 -g -O2 -DHAVE_CONFIG_H -o gengenrtl \ gengenrtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./gengenrtl tmp-genrtl.h tmp-genrtl.c make[2]: *** [s-genrtl] Segmentation Fault make[2]: Leaving directory `/home/papadopo/gcc-2.95.1/gcc' make[1]: *** [bootstrap] Error 2 make[1]: Leaving directory `/home/papadopo/gcc-2.95.1/gcc' make: *** [bootstrap] Error 2 $ 2) - egcs-1.1.2 uses GNU as and ld following the FAQ instructions - /bin is in the PATH I am able to build GCC 2.95.1. The resulting compiler yields warnings at link-time: $ cat foo.cc #include main() { cerr << "foo" << endl; } $ g++ -o foo foo.cc ld: warning: file /pub_dom/gcc-2.95.1/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/libstdc++.so: section .stabstr: malformed string table, initial or final byte $ Is this a bug (incompatibility) in GNU or Sun ld. Any info somenone? 3) - egcs-1.1.2 does _not_ use GNU as and ld - directory /usr/ccs/bin is in the PATH, so Sun as and ld are available I am able to build GCC 2.95.1. The resulting compiler seems to be able to build with Sun's as and ld. I haven't tried it extensively. Can someone explain why case 1 results in a segfault? Thank you in advance, -- Dimitri Papadopoulos From gcc-return-9271-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 15:16:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9326 invoked by alias); 20 Aug 1999 15:15:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9311 invoked from network); 20 Aug 1999 15:15:58 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by egcs.cygnus.com with SMTP; 20 Aug 1999 15:15:58 -0000 Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id LAA10322; Fri, 20 Aug 1999 11:15:47 -0400 Received: from marc.watson.ibm.com (marc.watson.ibm.com [9.2.176.11]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id LAA18412; Fri, 20 Aug 1999 11:15:46 -0400 Received: from localhost by marc.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA42288; Fri, 20 Aug 1999 11:15:46 -0400 Message-Id: <9908201515.AA42288@marc.watson.ibm.com> To: Takis Psarogiannakopoulos Cc: gcc@gcc.gnu.org Subject: Re: DGUX In-Reply-To: Message from Takis Psarogiannakopoulos of "Fri, 20 Aug 1999 00:54:36 PDT." Date: Fri, 20 Aug 1999 11:15:46 -0400 From: David Edelsohn GCC is built knowing a target directory for its internal files. You should not need to move those files. If you need to move the public binaries, fine. Are you saying that convoluted DG/ux elink procedure needs to access the private version of cpp? I cannot understand why that would be necessary. elink should be able to use an ISO compliant cpp provided by xcpp. David From gcc-return-9272-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 15:26:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11360 invoked by alias); 20 Aug 1999 15:26:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11331 invoked from network); 20 Aug 1999 15:26:17 -0000 Received: from gw-nl3.philips.com (@192.68.44.35) by egcs.cygnus.com with SMTP; 20 Aug 1999 15:26:17 -0000 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl3.philips.com with ESMTP id RAA14278 for ; Fri, 20 Aug 1999 17:26:12 +0200 (MEST) (envelope-from j.j.f.van.eijck@philips.com) From: j.j.f.van.eijck@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a) id xma014276; Fri, 20 Aug 99 17:26:12 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA23776 for ; Fri, 20 Aug 1999 17:26:11 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA21150 for ; Fri, 20 Aug 1999 17:26:11 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890004864354; Fri, 20 Aug 1999 17:26:11 +0200 To: Subject: gcc for C4x Message-ID: <0056890004864354000002L942*@MHS> Date: Fri, 20 Aug 1999 17:26:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 08/20/99 17:26:03" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, A few question about gcc-2.95.1 for C4x: 1) I'm using binutils-2.7 with a patch from Michael Hayes, but I' m won= dering have the c4x not been included in a later binutils. 2) Michael Hayes wrote: > However, the code produced by gcc-2.95 for the C30/C40 DSPs > results in poor benchmark times for the following reasons. > 1. It does not emit the fast block repeat instructions. > 2. It does not software pipeline loops to utilise parallel instructi= ons. > 3. Auto-increment addressing modes are not well utilised. > 4. Induction variable combination is poor. > 5. Delay slot filling is sub-optimal. > > To address the first two points, I submitted patches to egcs-patches > many months ago that seem to have been piped to /dev/null :-) > To address the third point I have written a pass that generates > def-use chains that are then scanned for instructions to be combined > t o utilise auto-increment (and auto-modify) addressing modes. This > seems to work well but I do not have the time at present to thoroughl= ytest it. >=20 > Hopefully Joern will sort out the fourth problem with his work on > strength reduction :-) (I still get better strength reduction of > induction variables on the C4x with gcc-2.7) >=20 > Improvements to delay slot filling require large hacks to reorg. Thi= s > has never worked well with multiple delay slots as the folks working > on the SHARC port are also finding. Is their be a patch for gcc-2.95.1 to solve a least the first two point= s. I didn't find any changes in Changelog file for C4x between the release= s of 2.95 and 2.95.1 - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - = + - + - + - + - + - +=20 ing. Jurge J.F.J. van Eijck (ICT Automatisering) CFT Mechatronics - Semiconductor Equipment Research Location: NatLab, WY p 38, phone: 040 - 27 43976 Location: CFT, SFK 061, phone: 040 - 27 39229 Reply to: J.J.F.van.Eijck@Philips.com Private Homepage : http://home.ict.nl/~jureijck - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - = + - + - + - + - + - +=20 = From gcc-return-9273-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 15:36:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13257 invoked by alias); 20 Aug 1999 15:36:36 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13242 invoked from network); 20 Aug 1999 15:36:34 -0000 Received: from fw-us-hou-2.bmc.com (HELO tangelo.bmc.com) (198.207.223.251) by egcs.cygnus.com with SMTP; 20 Aug 1999 15:36:34 -0000 Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA06652; Fri, 20 Aug 1999 10:36:26 -0500 (CDT) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 20 Aug 1999 10:36:26 -0500 Message-ID: <618C9ED0E58FD211B19100A0C9EAF0CF1B7DFF@es01-bos> From: "Dana, Eric" To: "'Dimitri Papadopoulos'" , gcc@gcc.gnu.org Subject: RE: GCC 2.95.1 'make bootstrap' oddities on Solaris Date: Fri, 20 Aug 1999 10:35:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Dimitri, I experienced the same results with Solaris 2.5 and 2.6. I worked the problem by: 1.) Use binutils 2.9.1 as/ld for the gcc 2.95.1 2.) Set my path to: PATH=.:/output-dir/bin:/bin:/usr/bin:/usr/ccs/bin Where 'output-dir- is the prefix directory. It seems if /usr/local/bin was in my path, the build would fail just like yours. --Eric-- -----Original Message----- From: Dimitri Papadopoulos [mailto:papadopo@shfj.cea.fr] Sent: Friday, August 20, 1999 11:00 AM To: gcc@gcc.gnu.org Subject: GCC 2.95.1 'make bootstrap' oddities on Solaris Hello, I am trying to 'make bootstrap' GCC 2.95.1 on Solaris 7. I got some segfaults during build, but finally managed to build GCC. I would appreciate some insight on what did happen. The initial situation is as follows: - The previously installed compiler is egcs-1.1.2. - /usr/ucb is not in the PATH and /usr/ccs/bin contains Sun's as and ld with the latest patches available (107058-01 for as). - The egcs-1.1.2 compiler may use GNU as and GNU ld from binutils-2.9.1. This is achieved following the FAQ instructions: cd /lib/gcc-lib/sparc-sun-solaris2.7/egcs-2.91.66 ln -s /bin/as ln -s /bin/ld Then I try to build GCC 2.95.1. Here are 3 different scenarios: 1) - egcs-1.1.2 uses GNU as and ld following the FAQ instructions - directory /usr/ccs/bin is in the PATH, so Sun as and ld are available I get a segfault: $ ./configure --enable-shared $ make bootstrap [...] stage1/xgcc -Bstage1/ -B/pub_dom/gcc-2.95.1/sparc-sun-solaris2.7/bin/ -DIN_GCC -DHAIFA -DSVR4 -O2 -g -O2 -DHAVE_CONFIG_H -o gengenrtl \ gengenrtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./gengenrtl tmp-genrtl.h tmp-genrtl.c make[2]: *** [s-genrtl] Segmentation Fault make[2]: Leaving directory `/home/papadopo/gcc-2.95.1/gcc' make[1]: *** [bootstrap] Error 2 make[1]: Leaving directory `/home/papadopo/gcc-2.95.1/gcc' make: *** [bootstrap] Error 2 $ 2) - egcs-1.1.2 uses GNU as and ld following the FAQ instructions - /bin is in the PATH I am able to build GCC 2.95.1. The resulting compiler yields warnings at link-time: $ cat foo.cc #include main() { cerr << "foo" << endl; } $ g++ -o foo foo.cc ld: warning: file /pub_dom/gcc-2.95.1/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/libstdc++.so: section .stabstr: malformed string table, initial or final byte $ Is this a bug (incompatibility) in GNU or Sun ld. Any info somenone? 3) - egcs-1.1.2 does _not_ use GNU as and ld - directory /usr/ccs/bin is in the PATH, so Sun as and ld are available I am able to build GCC 2.95.1. The resulting compiler seems to be able to build with Sun's as and ld. I haven't tried it extensively. Can someone explain why case 1 results in a segfault? Thank you in advance, -- Dimitri Papadopoulos From gcc-return-9274-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 16:03:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16575 invoked by alias); 20 Aug 1999 16:03:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16560 invoked from network); 20 Aug 1999 16:03:31 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 20 Aug 1999 16:03:31 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id IAA07013; Fri, 20 Aug 1999 08:56:15 -0700 Message-Id: <199908201556.IAA07013@zack.bitmover.com> To: Takis Psarogiannakopoulos cc: gcc@gcc.gnu.org Subject: dg/ux port issues In-Reply-To: Your message of "Fri, 20 Aug 1999 01:24:23 PDT." Date: Fri, 20 Aug 1999 08:56:15 -0700 From: Zack Weinberg Takis Psarogiannakopoulos wrote: > > Folks, > I am not sending that to the list since there is > no reason to overwhelm it with endless messages. Please don't do this. Keep discussion on the list. I don't know everything. > To:Jeffrey A Law: > Eric Raskin was working (as you probably know) > with egcs-1.1.2. He was trying to fix the dwarf-2. > The dtl program of DG/ux is buggy. That is the main > reason that gcc can not produce dwarf-2 debug in DG/ux. > DG refuse to fix it... Good or bad DGUX has its own ways. > I am not going to after DG to do that and this. This has nothing to do with cpp... > libgcc.a is being accessed also from elink. It should not be necessary. If you cannot link a program with gcc, that is a bug in the specs, which needs to be fixed. Your example: > link as : > -lgcc -lthread -lc !!! (using ld and not gcc) > If --prefix was /usr/sde/ix86dgux/usr/lib I could nt see clearly > the libgcc.a. has something deeply wrong with it. libgcc should have no dependencies on libc, for one thing. > What we looking here is just a simple rule in the gcc/Makefile > possible to compile a complete cpp (and not in two parts), > as it was in 2.8.1. It can be only for DG/ux. We will not do this. Leave the internal cpp in lib/gcc-lib/whatever/2.95/cpp. Put bin/cpp in the elink directory. If that doesn't work, please explain what goes wrong with it in excruciating detail, and maybe we can fix it. > > > > What are the missing features of the "external cpp" as you call it? > > > > I cannt remember since I switced back to gcc-2.8.1 I will build > tonight a gcc-2.95 and then an XFree86-3.3.5 I and will get back to > you. Ok. zw From gcc-return-9275-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 16:23:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19788 invoked by alias); 20 Aug 1999 16:22:46 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19771 invoked from network); 20 Aug 1999 16:22:40 -0000 Received: from nenuphar.saclay.cea.fr (132.166.192.7) by egcs.cygnus.com with SMTP; 20 Aug 1999 16:22:40 -0000 Received: from muguet.saclay.cea.fr (muguet.saclay.cea.fr [132.166.192.6]) by nenuphar.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.0.D20) with ESMTP id SAA23493 for ; Fri, 20 Aug 1999 18:22:37 +0200 (MET DST) Received: from pendragon-int.shfj.cea.fr (pendragon.shfj.cea.fr [132.166.81.1]) by muguet.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.1.D20) with SMTP id SAA12129; Fri, 20 Aug 1999 18:22:36 +0200 (MET DST) Received: by pendragon-int.shfj.cea.fr; id SAA28582; Fri, 20 Aug 1999 18:16:28 +0200 Received: from uriens.shfj.cea.fr(193.48.23.6) by pendragon-int.shfj.cea.fr via smap (3.2) id xma028580; Fri, 20 Aug 99 18:16:13 +0200 Received: from orcanie.shfj.cea.fr by shfj.cea.fr (8.6.10/PROTO-CEANET-3.0) with ESMTP id SAA04522 ; Fri, 20 Aug 1999 18:21:40 +0200 Received: from orcanie (orcanie [193.48.23.116]) by orcanie.shfj.cea.fr (8.9.1b+Sun/8.9.1) with SMTP id SAA05820; Fri, 20 Aug 1999 18:22:33 +0200 (MET DST) Message-Id: <199908201622.SAA05820@orcanie.shfj.cea.fr> Date: Fri, 20 Aug 1999 18:22:33 +0200 (MET DST) From: Dimitri PAPADOPOULOS-ORFANOS Reply-To: Dimitri PAPADOPOULOS-ORFANOS Subject: RE: GCC 2.95.1 'make bootstrap' oddities on Solaris To: gcc@gcc.gnu.org, Eric_Dana@bmc.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: J9Vq++qGEpUTYgetsftTMQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc > Dimitri, > > I experienced the same results with Solaris 2.5 and 2.6. I worked > the problem by: > > 1.) Use binutils 2.9.1 as/ld for the gcc 2.95.1 > > 2.) Set my path to: > > PATH=.:/output-dir/bin:/bin:/usr/bin:/usr/ccs/bin > > Where 'output-dir- is the prefix directory. > It seems if /usr/local/bin was in my path, the build would fail > just like yours. Thanks for your reply. This works fine indeed. However, I want one GNU as/ld version of GCC and one Sun as/ld version. I managed to build both of them. I will test and eventually use the Sun as/ld version, in order to be able to share libraries with people using the Sun as/ld. Once you begin to use GNU as/ld, you get stuck with it, because GNU ld is not compatible with Sun ld - see for example those nasty warnings: section .stabstr: malformed string table, initial or final byte I don't know if this is a Sun or GNU, an as or ld bug? Dimitri From gcc-return-9276-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 16:27:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20990 invoked by alias); 20 Aug 1999 16:27:21 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20966 invoked from network); 20 Aug 1999 16:27:14 -0000 Received: from mailer.shiprps.com (208.244.36.224) by egcs.cygnus.com with SMTP; 20 Aug 1999 16:27:14 -0000 Received: from mailhub3.calibersys.com (mailhub.calibersys.com [208.244.36.245]) by mailer.shiprps.com (8.9.1/8.8.7) with ESMTP id MAA18882 for ; Fri, 20 Aug 1999 12:23:45 -0400 Received: from pmail.vikingfreight.com ([40.176.200.40]) by mailhub3.calibersys.com (8.8.7/8.8.7) with ESMTP id MAA10688 for ; Fri, 20 Aug 1999 12:11:10 -0400 Received: by PMAIL with Internet Mail Service (5.5.2448.0) id ; Fri, 20 Aug 1999 09:26:46 -0700 Message-ID: From: Pham-Tri To: "'gcc@gcc.gnu.org'" Subject: gcc configuration Date: Fri, 20 Aug 1999 09:26:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" I have a sun server running solaris v2.6. Previously I temporary install the sun C compiler. I think it expired now. When I ran the GCC cofigure I got some errors. Do you have any idea? [mars(root):/opt/gcc-2.95.1]#./configure Configuring for a sparc-sun-solaris2.6 host. Created "Makefile" in /opt/gcc-2.95.1 using "mh-frag" License Error : Cannot connect to the license server. for product(Sun WorkShop Compiler C). (License server may not have been started) No SERVER lines in license file (-13,66:146) Connection refused cc: acomp failed for conftest.c *** The command 'cc -o conftest -g conftest.c' failed. *** You must set the environment variable CC to a working compiler. Thank you in advance for your help. Tri pham pham-tri@vikingfreight.com From gcc-return-9277-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 17:57:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2269 invoked by alias); 20 Aug 1999 17:57:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2240 invoked from network); 20 Aug 1999 17:56:58 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 20 Aug 1999 17:56:58 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id TAA23011; Fri, 20 Aug 1999 19:53:27 +0200 (MET DST) Date: Fri, 20 Aug 1999 19:53:25 +0200 (MET DST) From: Gerald Pfeifer To: Pham-Tri cc: "'gcc@gcc.gnu.org'" Subject: Re: gcc configuration In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 20 Aug 1999, Pham-Tri wrote: > I have a sun server running solaris v2.6. Previously I temporary > install the sun C compiler. I think it expired now. When I ran the > GCC cofigure I got some errors. Do you have any idea? Yes. To bootstrap a compiler you already need a compiler! In other words, to compile GCC you already need an installed compiler. However Sun C does not work any more due to a license (server) problem, so GCC's configure machinery prints an error message. > *** The command 'cc -o conftest -g conftest.c' failed. > *** You must set the environment variable CC to a working compiler. Please have a look at http://gcc.gnu.org/install/specific.html where I added some further information a few days ago. Hope this helps, Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9278-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 18:12:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6920 invoked by alias); 20 Aug 1999 18:12:35 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6903 invoked from network); 20 Aug 1999 18:12:34 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 20 Aug 1999 18:12:34 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA03184; Fri, 20 Aug 1999 11:12:32 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id LAA10233; Fri, 20 Aug 1999 11:12:32 -0700 (PDT) Date: Fri, 20 Aug 1999 11:12:32 -0700 (PDT) Message-Id: <199908201812.LAA10233@kankakee.wrs.com> To: Pham-Tri@vikingfreight.com, gcc@gcc.gnu.org Subject: Re: gcc configuration > From: Pham-Tri > To: "'gcc@gcc.gnu.org'" > Date: Fri, 20 Aug 1999 09:26:44 -0700 > I have a sun server running solaris v2.6. Previously I temporary > install the sun C compiler. I think it expired now. When I ran the > GCC cofigure I got some errors. Do you have any idea? Sure, Sun decided to screw you by putting a license manager on their compiler. There is something wrong on your system with the license manager. You need to contact you systems people and let them know. You can find and install binaries for gcc, and use those to compile up the compiler. From gcc-return-9279-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 19:39:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28486 invoked by alias); 20 Aug 1999 19:39:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28468 invoked from network); 20 Aug 1999 19:39:24 -0000 Received: from fw-ext.ascend.com (198.4.92.5) by egcs.cygnus.com with SMTP; 20 Aug 1999 19:39:24 -0000 Received: from tucson-net-86.eng.ascend.com by fw-ext.ascend.com via smtpd (for egcs.cygnus.com [205.180.83.80]) with SMTP; 20 Aug 1999 19:39:23 UT Received: (from gkm@localhost) by tucson-net-82.eng.ascend.com (8.8.7/8.8.7) id JAA32136; Fri, 20 Aug 1999 09:38:42 -1000 To: gcc@gcc.gnu.org Subject: Re: MIPS and the frame pointer (non)chain References: <199908200905.XAA31173@tucson-net-82.eng.ascend.com> From: Greg McGary Date: 20 Aug 1999 09:38:01 -1000 In-Reply-To: Greg McGary's message of "Thu, 19 Aug 1999 23:05:10 -1000" Message-ID: Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.4 Greg McGary writes: > ... Yes, there is a > pedantic reason, but IMO it's not a *good* one: the MIPS ABI (SysV ABI > MIPS supplement 3ed) states on page 3-15 that "Registers are saved in > numerical order, with higher numbered registers saved in higher memory > addresses". Furthermore, figure 3-21 on page 3-16 shows that the > floating-point register save area resides at lower address than the > general register save area. In order for the saved $fp and $ra to be > at fixed offset from the current $fp, the saved GP regs must trade > places with the saved FP regs. I momentarily forgot about the ".mask" assembler directive which encodes what registers are saved. Anyone reading the mask from symbol-table will assume that registers are stored in ascending order. The ".mask" is ignored for STABS, but not for ECOFF and ELF. Therefore, we can't a true frame pointer chain for binaries with non-STABS debugging. From gcc-return-9280-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 19:42:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29649 invoked by alias); 20 Aug 1999 19:42:42 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29634 invoked from network); 20 Aug 1999 19:42:40 -0000 Received: from news-ma.rhein-neckar.de (193.197.90.3) by egcs.cygnus.com with SMTP; 20 Aug 1999 19:42:40 -0000 Received: from arthur.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id VAA01113 for egcs@sourceware.cygnus.com; Fri, 20 Aug 1999 21:42:33 +0200 (CEST) (envelope-from aj@arthur.rhein-neckar.de) Received: from [192.168.27.2] (helo=raq2.rhein-neckar.de) by arthur.rhein-neckar.de with esmtp (Exim 3.02 #1) id 11HuYM-0004dN-00 for egcs@sourceware.cygnus.com; Fri, 20 Aug 1999 21:42:18 +0200 Received: (from admin@localhost) by raq2.rhein-neckar.de (8.9.3/8.9.3) id VAA06182; Fri, 20 Aug 1999 21:42:19 +0200 Date: Fri, 20 Aug 1999 21:42:19 +0200 Message-Id: <199908201942.VAA06182@raq2.rhein-neckar.de> X-Authentication-Warning: raq2.rhein-neckar.de: admin set sender to admin@raq2.rhein-neckar.de using -f From: Administrator To: egcs@sourceware.cygnus.com Subject: build 2.95.1 on mipsel-linux I just wanted to say that I build 2.95.1 on (output from config.guess: mipsel-unknown-linux-gnu) an Cobalt Raq2. If you put this up on your web page, please note that it's neccessary to add a small patch to gcc/config/mips/linux.h (see gcc-patches). I'm impressed that gcc bootstrapped and checked without major problems. Congretulations! Andreas From gcc-return-9281-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 20:14:12 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3682 invoked by alias); 20 Aug 1999 20:14:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3666 invoked from network); 20 Aug 1999 20:14:06 -0000 Received: from smtp.interlog.com (root@207.34.202.37) by egcs.cygnus.com with SMTP; 20 Aug 1999 20:14:06 -0000 Received: from crjnt2 (cj.interlog.com [199.212.157.174]) by smtp.interlog.com (8.9.1/8.9.1) with SMTP id QAA13990 for ; Fri, 20 Aug 1999 16:14:03 -0400 (EDT) Message-Id: <3.0.32.19990820161538.009b0100@mail.interlog.com> X-Sender: cj@mail.interlog.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Aug 1999 16:15:39 -0400 To: egcs@egcs.cygnus.com From: "Christopher R. Jones" Subject: gcc-2.95.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" gcc-2.95.1 successfully built and installed on Solaris 7, Intel. Used gcc-2.8.1 compiler from sunfreeware.com Now I am trying to configure and build esp-r. Anyone there managed to do this? Christopher R. Jones, P.Eng. 14 Oneida Avenue Toronto, Ontario M5J 2E3 Tel. 416 203-7465 Fax. 416 203-3044 Email cj@interlog.com From gcc-return-9282-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 20:15:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4458 invoked by alias); 20 Aug 1999 20:15:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4435 invoked from network); 20 Aug 1999 20:15:36 -0000 Received: from atrey.karlin.mff.cuni.cz (hubicka@195.113.31.123) by egcs.cygnus.com with SMTP; 20 Aug 1999 20:15:36 -0000 Received: (from hubicka@localhost) by atrey.karlin.mff.cuni.cz (8.8.8/8.8.8) id WAA05281; Fri, 20 Aug 1999 22:15:36 +0200 Message-ID: <19990820221536.48077@atrey.karlin.mff.cuni.cz> Date: Fri, 20 Aug 1999 22:15:36 +0200 From: Jan Hubicka To: egcs@egcs.cygnus.com Subject: Yes another function attribute? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 After recend discussion about __attribute__ ((const)) one other attribute comes into mind. While true const function are rare IMO, on the other hand there are quite a lot functions that only reads memory and calculates something. The predicates in gcc to name few. Maybe it can be benefical to add attribute for this class of funcitons. While it is not so strong as const, it stills avoids flusing of cse tables and in case no global memory is modified they can be handled as const funcitons too. Also GCC would know that call of such function can be ignored once return value is dead. Do you think it worth the implementation? Any suggestion for name of the atribute? (readonly comes into mind :) There is philosofical question where to stop now. Once such attribute is implemented one should ask for another that express fact, that memory is only written etc.... I still believe that such attribute is worthwhile. At least the insn-attrtab and insn-recog code can greatly benefit from it (so variables like operand or which_alternative will get CSEed). Honza -- OK. Lets make a signature file. +-------------------------------------------------------------------------+ | Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz | | Czech free software foundation: http://www.freesoft.cz | |AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa | | homepage: http://www.paru.cas.cz/~hubicka/, games koules, Xonix, fast | | fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc. | +-------------------------------------------------------------------------+ From gcc-return-9283-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 20:32:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6744 invoked by alias); 20 Aug 1999 20:32:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6728 invoked from network); 20 Aug 1999 20:32:20 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 20 Aug 1999 20:32:20 -0000 Received: from localhost (george@localhost) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id QAA17537; Fri, 20 Aug 1999 16:30:37 -0400 Date: Fri, 20 Aug 1999 16:30:37 -0400 (EDT) From: George Talbot To: Jason Merrill cc: gcc@gcc.gnu.org Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 19 Aug 1999, Jason Merrill wrote: > >>>>> George T Talbot writes: > > > Jason Merrill wrote: > >> > >> No; cleanups are registered at compile time in the dwarf2 model. You'll > >> need to extend the C frontend to add the notion of cleanups, like a try > >> ... finally construct, or a cleanup block construct. > > > Ugh. This is starting to get beyond my skill level. I can do the C > > library stuff, but I'm not sure I understand how to extend the compiler > > this way. > > Actually, the simplest approach would be to make them builtin functions, > __builtin_cleanup_push (routine, arg) and __builtin_cleanup_pop (execute). > You would call expand_eh_region_start_tree in stmt.c to register the > cleanup, and if execute is true when popping, extract the cleanup info from > the ehstack and run it directly. It would be hard to map the existing API > onto try ... finally. So, these would be functions that GCC would generate into the program on-the-fly? Makes sense. > >> > If I can do that, then I can rewrite pthread_cleanup_push() and > >> > pthread_cleanup_pop() to work with the exception mechanism and I can > >> > rewrite pthread_cancel() to throw an exception. > >> > >> push and pop would need to be macros. > > > Yup. They are now, if you look at pthreads.h. > > And I see that they are required to be symmetrical, at the same nesting > level. Good; this is crucial for the compile-time approach to work. The POSIX standard is written that way for just this issue. -George P.S. Thanks for helping me work through this. From gcc-return-9284-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 20:56:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10632 invoked by alias); 20 Aug 1999 20:55:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10608 invoked from network); 20 Aug 1999 20:55:50 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 20 Aug 1999 20:55:50 -0000 Received: from cs.ucla.edu (ts37-11.wla.ts.ucla.edu [164.67.22.88]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id NAA06079; Fri, 20 Aug 1999 13:55:48 -0700 (PDT) Message-ID: <37BDC18C.C3874DA2@cs.ucla.edu> Date: Fri, 20 Aug 1999 13:58:52 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Successful install on Solaris 2.7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit gcc 2.95-1 install went cleaner than gcc 2.95 (we had weird linking problems with the latter). However, the bugs I discovered with 2.95 are still in 2.95-1 ... see the bug report w sample code in gcc-bugs http://egcs.cygnus.com/ml/gcc-bugs/1999-08/msg00347.html (unless there is some reason it's not a bug ! ;-) more to come Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-9285-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 20 21:26:12 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17968 invoked by alias); 20 Aug 1999 21:26:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17930 invoked from network); 20 Aug 1999 21:26:05 -0000 Received: from igc7.igc.org (192.82.108.35) by egcs.cygnus.com with SMTP; 20 Aug 1999 21:26:05 -0000 Received: from igce.igc.org (igce.igc.org [192.82.108.49]) by igc7.igc.org (8.9.3/8.9.3) with ESMTP id OAA18406 for ; Fri, 20 Aug 1999 14:24:44 -0700 (PDT) Received: (from root@localhost) by igce.igc.org (8.9.3/8.9.3) id OAA23092; Fri, 20 Aug 1999 14:17:49 -0700 (PDT) Date: Fri, 20 Aug 1999 14:17:49 -0700 (PDT) Message-Id: <199908202117.OAA23092@igce.igc.org> From: Scott Weikart To: gcc@gcc.gnu.org CC: scott@igc.org Subject: gcc-2.95.1 successfully installs on Solaris 2 for Intel igce[/tmp/src/gcc]-2215# gcc-2.95.1/config.guess i386-pc-solaris2.6 igce[/tmp/src/gcc]-2216# gcc --version 2.95.1 igc3[~scott]-2079# rsh2 igcb "cd /tmp/src/gcc && gcc-2.95.1/config.guess && gcc --version" i386-pc-solaris2.5.1 2.95.1 igc7[/tmp/src/gcc]-954# gcc-2.95.1/config.guess i386-pc-solaris2.5 igc7[/tmp/src/gcc]-955# gcc --version 2.95.1 From gcc-return-9286-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 01:02:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21664 invoked by alias); 21 Aug 1999 01:02:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21643 invoked from network); 21 Aug 1999 01:01:59 -0000 Received: from igcb.igc.org (192.82.108.46) by egcs.cygnus.com with SMTP; 21 Aug 1999 01:01:59 -0000 Received: from igce.igc.org (igce.igc.org [192.82.108.49]) by igcb.igc.org (8.9.2/8.9.2) with ESMTP id SAA17923 for ; Fri, 20 Aug 1999 18:01:18 -0700 (PDT) Received: (from root@localhost) by igce.igc.org (8.9.3/8.9.3) id SAA24938; Fri, 20 Aug 1999 18:01:17 -0700 (PDT) Date: Fri, 20 Aug 1999 18:01:17 -0700 (PDT) Message-Id: <199908210101.SAA24938@igce.igc.org> From: Scott Weikart To: gcc@gcc.gnu.org Subject: gcc-2.95.1 successfully installs on SunOS 4.1.3 cdp[/re/tmp/src/cdp/gcc]-2079# gcc-2.95.1/config.guess sparc-sun-sunos4.1.3 cdp[/re/tmp/src/cdp/gcc]-2080# gcc --version 2.95.1 But I had to apply the following patch to make sure /usr/include/utime.h was fixed. -scott ============================================================================= Date: Fri, 20 Aug 1999 17:57:13 -0700 (PDT) Message-Id: <199908210057.RAA24115@igce.igc.org> From: Scott Weikart To: gcc-bugs@gcc.gnu.org CC: scott@igc.org Subject: bug in fix-header for SunOS 4.1.3 I got a coredump when fix-header tried to fix utime.h; here's my gdb session: gdb fix-header (gdb) Breakpoint 2 at 0xda80: file ../gcc-2.95.1/gcc/fix-header.c, line 1140. (gdb) run utime.h /usr/include/utime.h /re/tmp/src/cdp/gcc/gcc/include/utime.h -D__STDC__=0 -D__cplusplus -I/re/tmp/src/cdp/gcc/gcc/include -I/usr/include Breakpoint 2, main (argc=8, argv=0xeffff02c) at ../gcc-2.95.1/gcc/fix-header.c:1140 (gdb) p entry[0] $1 = {name = 0x99d8 "utime.h", flags = 0, names = 0x99d0 "utime"} (gdb) p entry[1] $2 = {name = 0x0, flags = 0, names = 0x30a88 ""} Here's the code fragment in question: for (entry = include_entry; ;) { => if (entry->flags) add_symbols (entry->flags, entry->names); entry++; if (strcmp (entry->name, CONTINUED) != 0) break; } Since I don't really know what's going on, I used this brute-force patch to make it work: --- gcc-2.95.1/gcc/fix-header.c~ Mon Aug 2 00:38:04 1999 +++ gcc-2.95.1/gcc/fix-header.c Fri Aug 20 17:42:37 1999 @@ -1140,7 +1140,7 @@ if (entry->flags) add_symbols (entry->flags, entry->names); entry++; - if (strcmp (entry->name, CONTINUED) != 0) + if (!entry->name || strcmp (entry->name, CONTINUED) != 0) break; } } And here's the fixed file that was generated. -scott ============================================================================= /* @(#)utime.h 1.3 89/06/25 SMI; from S5R2 1.1 */ #ifndef __utime_h #ifndef _PARAMS #if defined(__STDC__) || defined(__cplusplus) #define _PARAMS(ARGS) ARGS #else #define _PARAMS(ARGS) () #endif #endif /* _PARAMS */ #define __utime_h #include /* * POSIX utime.h, utime() calls utimes() */ struct utimbuf { time_t actime; /* set the access time */ time_t modtime; /* set the modification time */ }; int utime _PARAMS((const char *, const struct utimbuf *)); #endif /* !__utime_h */ From gcc-return-9287-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 03:30:40 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 621 invoked by alias); 21 Aug 1999 03:30:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 605 invoked from network); 21 Aug 1999 03:30:36 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 21 Aug 1999 03:30:36 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id AAA07760; Sat, 21 Aug 1999 00:26:28 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id AAA10939; Sat, 21 Aug 1999 00:26:05 -0300 (EST) To: Jan Hubicka Cc: egcs@egcs.cygnus.com Subject: Re: Yes another function attribute? References: <19990820221536.48077@atrey.karlin.mff.cuni.cz> From: Alexandre Oliva Date: 21 Aug 1999 00:29:52 -0300 In-Reply-To: Jan Hubicka's message of "Fri, 20 Aug 1999 22:15:36 +0200" Message-ID: Lines: 12 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 20, 1999, Jan Hubicka wrote: > Do you think it worth the implementation? Any suggestion for name of the > atribute? (readonly comes into mind :) stateless? idempotent? -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9288-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 03:33:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1608 invoked by alias); 21 Aug 1999 03:33:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1589 invoked from network); 21 Aug 1999 03:33:52 -0000 Received: from field.medicine.adelaide.edu.au (129.127.174.19) by egcs.cygnus.com with SMTP; 21 Aug 1999 03:33:52 -0000 Received: (qmail 4652 invoked from network); 21 Aug 1999 03:37:31 -0000 Received: from wendy114.zip.com.au (HELO field.medicine.adelaide.edu.au) (colin@61.8.18.114) by field.medicine.adelaide.edu.au with SMTP; 21 Aug 1999 03:37:31 -0000 X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: gcc@gcc.gnu.org Subject: Q: size of class/struct Reply-To: colin@field.medicine.adelaide.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Aug 1999 13:33:44 +1000 From: Colin McCormack Hi, Is there anywhere in the output of gcc2.95 where the size of a class/struct is kept ... statically. It used to be in the vtable struct, but was removed for rtti. Does the rtti structure keep the information anywhere? Reason I'd like to know: I would like to be able to call a constructor having dlopen()ed the implementing code, but of course I don't know how much storage to allocate prior to the call. This is in reference to coldstore: http://field.medicine.adelaide.edu.au/~colin/coldstore/ which we're going to release fairly soon, and which incidentally, you may wish to check out. Colin. From gcc-return-9289-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 03:54:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3011 invoked by alias); 21 Aug 1999 03:54:30 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2996 invoked from network); 21 Aug 1999 03:54:28 -0000 Received: from atrey.karlin.mff.cuni.cz (hubicka@195.113.31.123) by egcs.cygnus.com with SMTP; 21 Aug 1999 03:54:28 -0000 Received: (from hubicka@localhost) by atrey.karlin.mff.cuni.cz (8.8.8/8.8.8) id FAA02965; Sat, 21 Aug 1999 05:54:14 +0200 Message-ID: <19990821055414.40740@atrey.karlin.mff.cuni.cz> Date: Sat, 21 Aug 1999 05:54:14 +0200 From: Jan Hubicka To: Alexandre Oliva Cc: egcs@egcs.cygnus.com Subject: Re: Yet another function attribute? References: <19990820221536.48077@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: ; from Alexandre Oliva on Sat, Aug 21, 1999 at 12:29:52AM -0300 > On Aug 20, 1999, Jan Hubicka wrote: > > > Do you think it worth the implementation? Any suggestion for name of the > > atribute? (readonly comes into mind :) > > stateless? idempotent? Interesting ideas. Here is another one: While implementing it (I am just doing last checks for first part of patch to handle such functions and detect them automatically) I found that it match closely "side_effects" attribute in gcc. So maybe "noside_effects" can be good name. But it does not represent the fact, that function also must be deterministics, so possibly someone will tend to add "noside_effects" to functions like inport, where it is wrong. Other is "readmemoryonly" attribute, but rather long name. (BTW it find roughly 300 such functions in gcc sources (only static ones are checked) and saves 8% of size in XaoS binarry) Honza > > -- > Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il > oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} > oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} > ** I may forward mail about projects to mailing lists; please use them -- OK. Lets make a signature file. +-------------------------------------------------------------------------+ | Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz | | Czech free software foundation: http://www.freesoft.cz | |AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa | | homepage: http://www.paru.cas.cz/~hubicka/, games koules, Xonix, fast | | fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc. | +-------------------------------------------------------------------------+ From gcc-return-9290-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 06:12:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10909 invoked by alias); 21 Aug 1999 06:11:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10885 invoked from network); 21 Aug 1999 06:11:56 -0000 Received: from newton.math.purdue.edu (root@128.210.3.6) by egcs.cygnus.com with SMTP; 21 Aug 1999 06:11:56 -0000 Received: from polya.math.purdue.edu (lucier@polya.math.purdue.edu [128.210.3.194]) by newton.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.3) with ESMTP id BAA09630; Sat, 21 Aug 1999 01:11:51 -0500 (EST) Received: (from lucier@localhost) by polya.math.purdue.edu (8.8.8/8.8.8/PURDUE_MATH-2.1) id BAA11895; Sat, 21 Aug 1999 01:11:49 -0500 (EST) Date: Sat, 21 Aug 1999 01:11:49 -0500 (EST) From: Brad Lucier Message-Id: <199908210611.BAA11895@polya.math.purdue.edu> To: lucier@math.purdue.edu, toon@moene.indiv.nluug.nl Subject: Re: sqrt on alphaev6 Cc: gcc@gcc.gnu.org, goeffk@cygnus.com X-Sun-Charset: US-ASCII Toon Moene wrote: > Brad Lucier wrote: > > > with -mcpu=ev6 -mieee on alphaev6 with gcc 2.95.1 the following code > > is typically generated for sqrt: > > > sqrttsu $f16,$f0 > > cmpteqsu $f0,$f0,$f10 ; check for NaN? > > fbne $f10,$L836 > > jsr $26,sqrt > > ldgp $29,0($26) > > $L836: > > > My question is whether the call to the sqrt routines is necessary > > for ev6. I find 21264hrm.pdf to be somewhat confusing, but it > > seems to imply that software completion is not needed on the 21264. > > According to the documentation accompanying gcc, one can specify the > following macro name for any target architecture (cpu/os combination): > > `TARGET_EDOM' > The value of `EDOM' on the target machine, as a C integer constant > expression. If you don't define this macro, GNU CC does not > attempt to deposit the value of `EDOM' into `errno' directly. > Look in `/usr/include/errno.h' to find the value of `EDOM' on your > system. > ... > > This constant is not defined for many targets: ... Geoff Keating wrote: > On most targets (certainly all linux, for instance), you can't do this because > the math error handling is more complicated than just setting errno. > > SVR4-derived code expects an application function called 'matherr' to > be called, for instance (yuk!). I think this is another IEEE arithmetic issue. I've just looked through the draft ISO C standard (with header [ISO/] [IEC] JTC1/SC22/WG14 N843) and it seems to say that error handling for sqrt should follow the IEEE arithmetic standard. Although I can't quite work through /usr/include/math.h in my linux distribution, it seems to imply that IEEE error handling is sometimes an option. So, if gcc with -mieee is not going to set EDOM for 1.0/0.0, but either (a) set the result to infinity and continue or (b) halt the program with a trap, depending on how the IEEE trap handler is set, then sqrt(-1.0) should do the same thing, depending on precisely the same trap handler. Brad Lucier lucier@math.purdue.edu From gcc-return-9291-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 09:12:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31303 invoked by alias); 21 Aug 1999 09:12:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31286 invoked from network); 21 Aug 1999 09:12:45 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 21 Aug 1999 09:12:45 -0000 Received: from alphard (alphard [128.130.111.37]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id LAA00809; Sat, 21 Aug 1999 11:12:41 +0200 (MET DST) Date: Sat, 21 Aug 1999 11:12:40 +0200 (MET DST) From: Gerald Pfeifer To: gcc@gcc.gnu.org cc: Jason Molenda Subject: Mailserver: DNS Check for From: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII How about enabling a DNS Check for the From: which is used to send mail to the egcs/gcc.gnu.org server? Replying to asocial guys like the following From: Chris Rankin is not possible and frustrating if one does not check carfully enough. Sendmail can do this kind of checks with a single line in the config files and I am sure that it should also be easy to do with qmail. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9292-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 11:31:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9188 invoked by alias); 21 Aug 1999 11:31:30 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9173 invoked from network); 21 Aug 1999 11:31:28 -0000 Received: from jolt.idonex.se (194.52.182.67) by egcs.cygnus.com with SMTP; 21 Aug 1999 11:31:28 -0000 Received: from lexx.idonex.se (lexx.idonex.se [194.52.182.166]) by jolt.idonex.se (8.8.8/8.8.8) with SMTP id NAA29154; Sat, 21 Aug 1999 13:31:25 +0200 (MET DST) To: Dimitri Papadopoulos Cc: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <3780F13B.3BCE13F8@club-internet.fr> X-Face: $$CzX_6%|HNr.oB"KTJp(4s)x@#{7`R#=qth)@YQVIW3G_vqiReP):T3il:o9H[)hjgs%QU z!Gx^:NL=B(KNK[Y7{`T*hok`uv`}ArWqZ\wF&KHgVYr+d\>oGI?I\60y?,j*xB@gkYk_)YU0]6"S` nEjNqCC Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: Mirar Date: 21 Aug 1999 13:31:24 +0200 In-Reply-To: Dimitri Papadopoulos's message of Mon, 05 Jul 1999 19:54:03 +0200 Message-ID: <826729mktv.fsf@lexx.idonex.se> Lines: 12 X-Mailer: Gnus v5.4.9/Emacs 19.34 > 1) The Solaris linker does not seem to work with egcs. Well, it works with > small examples, but consistently fails to link some of our larger > programs. I remember reading somewhere that this is a bug in the Solaris > linker. Additional info on this? Is there a patch to correct the bug? > Is there some way to work around this Solaris bug within egcs? Current > workaround: > - Use the GNU linker. As I said earlier, egcs/gcc generates illegal assembler lines for the relocation tables. But noone seems to care, anyway... /Mirar From gcc-return-9293-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 13:53:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8363 invoked by alias); 21 Aug 1999 13:52:53 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8346 invoked from network); 21 Aug 1999 13:52:38 -0000 Received: from unknown (HELO tapti.hss.hns.com) (139.85.242.19) by egcs.cygnus.com with SMTP; 21 Aug 1999 13:52:38 -0000 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id UAA01656 for ; Sat, 21 Aug 1999 20:44:18 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 652567D4.004BDDFB ; Sat, 21 Aug 1999 19:18:40 +0530 X-Lotus-FromDomain: HSS From: mnaik@hss.hns.com To: gcc@gcc.gnu.org Message-ID: <652567D4.004BDBD9.00@sandesh.hss.hns.com> Date: Sat, 21 Aug 1999 19:20:44 +0530 Subject: a suggestion for generating better code without -O in GCC Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I have a minor suggestion for improving the unoptimized code generated by gcc version 2.7.2.3: For the following C code fragment: if (a < b || c < d) printf("T"); else printf("F"); The following output is produced: *** output 1 *** if (a < b) goto L1 if (c < d) goto L1 goto L2 // this goto is redundant L1: printf("T") goto L3 L2: printf("F") L3: **************** The optimal output would be: *** output 2 *** if (a < b) goto L1 if (c >= d) goto L2 L1: printf("T") goto L3 L2: printf("F") L3: **************** Of course, with the -O flag, GCC generates output 2. Would it be worthwhile to generate output 2 without optimization? Thanks and Regards, Mayur From gcc-return-9294-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 15:51:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15228 invoked by alias); 21 Aug 1999 15:51:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15213 invoked from network); 21 Aug 1999 15:51:47 -0000 Received: from front1.grolier.fr (194.158.96.51) by egcs.cygnus.com with SMTP; 21 Aug 1999 15:51:47 -0000 Received: from dimitri.localdomain (ppp-108-227.villette.club-internet.fr [194.158.108.227]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id RAA20173; Sat, 21 Aug 1999 17:51:41 +0200 (MET DST) Received: from club-internet.fr (dimitri.localdomain [127.0.0.1]) by dimitri.localdomain (8.8.7/8.8.7/Dimitri) with ESMTP id RAA01089; Sat, 21 Aug 1999 17:45:34 +0200 Message-ID: <37BEC99E.9BCE3572@club-internet.fr> Date: Sat, 21 Aug 1999 17:45:34 +0200 From: Dimitri Papadopoulos X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: Mirar CC: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <3780F13B.3BCE13F8@club-internet.fr> <826729mktv.fsf@lexx.idonex.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mirar wrote: > > > 1) The Solaris linker does not seem to work with egcs. Well, it works with > > small examples, but consistently fails to link some of our larger > > programs. I remember reading somewhere that this is a bug in the Solaris > > linker. Additional info on this? Is there a patch to correct the bug? > > Is there some way to work around this Solaris bug within egcs? Current > > workaround: > > - Use the GNU linker. > > As I said earlier, egcs/gcc generates illegal assembler lines for the > relocation tables. But noone seems to care, anyway... First, thanks for the first sensible reply to my message. This would explain some other problems I have with EGCS/Solaris. In fact things are getting worse, as GCC 2.95.1 does not work on SPARC anymore: 1) GCC does not bootstrap with Sun's fully patched C compiler 5.0. This may be a problem with Sun's compiler, but I doubt it. In fact 'make bootstrap' will usually fail whatever the compiler used to bootstrap. See my messsage to this list: GCC 2.95.1 'make bootstrap' oddities on Solaris 2) Libraries built with GCC and GNU as/ld cannot be used with code built with GCC and Sun as/ld. You get warnings or even missing symbols. 3) I get segfault/aritmetic exception in Qt (http://www.troll.no/),even without -O. The problem is not with Qt: - The very same source compiled with egcs-1.1.2 or Sun CC does not crash. - I believe Qt is Purified. - The error is here: QCollection::Item QGDict::look_ascii( const char *key, QCollection::Item d, int op ) { QAsciiBucket *n; int index = hashKeyAscii(key) % vlen; The value of the 'vlen' is 0, which it can't be because 'this' is a valid (allocated and not yet deleted) QGDict pointer and QGDict never sets 'vlen' to 0. For those willing to reproduce this bug, build Qt-2.0.1 and run examples/application/application. Just choose menu item 'File|Quit' and click on button 'Leave Anyway' in the confirmation dialog. 4) GCC is not compatible with dbx, for reasons that have been discussed in this list before - Sun was not willing to disclose its debug format in the past. So it seems there are a few errors in the assembler generated by GCC: 1) EGCS/GCC generate illegal assembler lines for the relocation tables. The result is that shared objects generated with EGCS/GCC are not 100% compatible with Solaris shared objects. 2) Wrong assembler is generated by GCC 2.95.1 which sometimes results in segfaults. I'd like to fix these bugs, but I am not proficient in compilers. Does anyone have more details on these bugs? How to track bugs in the assembler code? Mirar, do you have more details on the relocation table bug so that I can file in a bug report and send it to gcc-bugs@gcc.gnu.org? I believe that fixing bugs 1 and 2 would resolve problems 1, 2 and 3, which are serious enough to prevent from using GCC 2.95.1 on SPARC/ Solaris. I understand that problem 4 is very low on the priority list. For the time being, on Solaris/SPARC: - Do not use GCC 2.95(.1). - Use EGCS 1.1.2 with optimisation level less or equal to -O2. -- Dimitri Papadopoulos From gcc-return-9295-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 15:56:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16604 invoked by alias); 21 Aug 1999 15:56:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16577 invoked from network); 21 Aug 1999 15:56:46 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 21 Aug 1999 15:56:46 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id MAA12505; Sat, 21 Aug 1999 12:52:30 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id MAA28220; Sat, 21 Aug 1999 12:52:30 -0300 (EST) To: Dimitri Papadopoulos Cc: Mirar , egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <3780F13B.3BCE13F8@club-internet.fr> <826729mktv.fsf@lexx.idonex.se> <37BEC99E.9BCE3572@club-internet.fr> From: Alexandre Oliva Date: 21 Aug 1999 12:56:22 -0300 In-Reply-To: Dimitri Papadopoulos's message of "Sat, 21 Aug 1999 17:45:34 +0200" Message-ID: Lines: 16 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 21, 1999, Dimitri Papadopoulos wrote: > 3) I get segfault/aritmetic exception in Qt (http://www.troll.no/),even > without -O. The problem is not with Qt: > - The very same source compiled with egcs-1.1.2 or Sun CC does not > crash. Did you try to compile with -fno-strict-aliasing? -fstring-aliasing, now enabled by default, has caused some problems to packages that use certain kinds of casts of pointers with undefined results. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9296-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 16:10:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17872 invoked by alias); 21 Aug 1999 16:10:39 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17857 invoked from network); 21 Aug 1999 16:10:36 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 21 Aug 1999 16:10:36 -0000 Received: from bolero.cs.tu-berlin.de (doko@bolero.cs.tu-berlin.de [130.149.19.1]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id SAA22224; Sat, 21 Aug 1999 18:06:13 +0200 (MET DST) Received: (from doko@localhost) by bolero.cs.tu-berlin.de (8.9.1/8.9.0) id SAA08723; Sat, 21 Aug 1999 18:06:12 +0200 (MET DST) From: Matthias Klose MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="P3aVkMoi86" Content-Transfer-Encoding: 7bit Date: Sat, 21 Aug 1999 18:06:12 +0200 (MET DST) To: gcc@gcc.gnu.org CC: 43170@bugs.debian.org Subject: Result naming doesn't work for functions defined in a class X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14270.52708.140409.985100@bolero> --P3aVkMoi86 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [This bug/behaviour was reported to me as a co-maintainer of the Debian GNU/Linux GCC packages. Please Cc: 43170@bugs.debian.org in your response so it gets archived in the Debian bugtracking system (http://www.debian.org/Bugs/db/43/43170.html).] --P3aVkMoi86 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=tKW2IUtsqtDRztdT Received: from master.debian.org (qmailr@master.debian.org [209.41.108.5]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with SMTP id TAA13475 for ; Wed, 18 Aug 1999 19:18:24 +0200 (MET DST) Received: (qmail 614 invoked by uid 1174); 18 Aug 1999 17:18:06 -0000 Delivered-To: doko@debian.org Received: (qmail 600 invoked by uid 978); 18 Aug 1999 17:18:05 -0000 Delivered-To: galenh-egcs@debian.org Received: (qmail 594 invoked by uid 847); 18 Aug 1999 17:18:05 -0000 Delivered-To: joey-packages-gcc@packages.debian.org Received: (qmail 576 invoked from network); 18 Aug 1999 17:18:04 -0000 Received: from master.debian.org (mail@209.41.108.5) by master.debian.org with SMTP; 18 Aug 1999 17:18:04 -0000 Received: from iwj by master.debian.org with local (Exim 2.05 #1 (Debian)) id 11H9Le-00008Y-00; Wed, 18 Aug 1999 12:18:02 -0500 Reply-To: Chris Butler , 43170@bugs.debian.org X-Debian-PR-Message: report 43170 X-Debian-PR-Package: gcc X-Loop: owner@bugs.debian.org Received: via spool by bugs@bugs.debian.org id=B.93499578119950 (code B ref -1); Wed, 18 Aug 1999 17:18:01 GMT Message-ID: <19990818152711.A29823@downstairs.db-bbs.com> X-Mailer: Mutt 0.95.6i Resent-From: Chris Butler Resent-To: debian-bugs-dist@lists.debian.org Resent-CC: Debian GCC maintainers Resent-Date: Wed, 18 Aug 1999 17:18:01 GMT Resent-Message-ID: Resent-Sender: iwj@debian.org From: Chris Butler To: Debian Bug Tracking System Subject: Bug#43170: Result naming doesn't work for functions defined in a class Date: Wed, 18 Aug 1999 15:27:11 +0100 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Package: gcc Version: 1:2.95.1-0pre1 Severity: normal Hi, The following code gives a parse error with BUG defined. Looking at the info docs, I don't think it should. Exact error messages: [downstairs:~] $ g++ -c test.cc [downstairs:~] $ g++ -DBUG -c test.cc test.cc:13: function body for constructor missing test.cc:13: parse error before `{' test.cc: In method `class string foo::do_foo(const string &)': test.cc:13: parse error before `;' test.cc:13: parse error at end of saved function text -- System Information Debian Release: potato Architecture: i386 Kernel: Linux downstairs 2.2.9 #5 Fri Jun 18 19:30:25 BST 1999 i686 Versions of packages gcc depends on: ii binutils 2.9.1.0.25-2 The GNU assembler, linker and bina ii cpp 1:2.95.1-0pre1 The GNU C preprocessor. ii libc6 2.1.2-0pre7 GNU C Library: Shared libraries an -- Chris Butler e-mail: -------------------------------------------------------------------------- PGP key 9D973385/1024 fingerprint: 047E 3689 387A 8C4B 709C 74A2 7AB3 4869 --tKW2IUtsqtDRztdT Content-Type: text/x-c++src Content-Disposition: attachment; filename="test.cc" #include #include string do_foo(const string& a) return ret; { ret = "foo" + a; } struct foo { string do_foo2(const string& a); #ifdef BUG string do_foo(const string& a) return ret; { ret = "foo" + a; } #endif }; string foo::do_foo2(const string& a) return ret; { ret = "foo" + a; } --tKW2IUtsqtDRztdT-- --P3aVkMoi86-- From gcc-return-9297-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 16:20:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18900 invoked by alias); 21 Aug 1999 16:20:12 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18882 invoked from network); 21 Aug 1999 16:20:09 -0000 Received: from front6.grolier.fr (194.158.96.56) by egcs.cygnus.com with SMTP; 21 Aug 1999 16:20:09 -0000 Received: from dimitri.localdomain (ppp-108-227.villette.club-internet.fr [194.158.108.227]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA29031; Sat, 21 Aug 1999 18:20:06 +0200 (MET DST) Received: from club-internet.fr (dimitri.localdomain [127.0.0.1]) by dimitri.localdomain (8.8.7/8.8.7/Dimitri) with ESMTP id SAA01207; Sat, 21 Aug 1999 18:14:36 +0200 Message-ID: <37BED06C.954DEC9F@club-internet.fr> Date: Sat, 21 Aug 1999 18:14:36 +0200 From: Dimitri Papadopoulos X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: Alexandre Oliva CC: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <3780F13B.3BCE13F8@club-internet.fr> <826729mktv.fsf@lexx.idonex.se> <37BEC99E.9BCE3572@club-internet.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alexandre Oliva wrote: > > On Aug 21, 1999, Dimitri Papadopoulos wrote: > > > 3) I get segfault/aritmetic exception in Qt (http://www.troll.no/),even > > without -O. The problem is not with Qt: > > - The very same source compiled with egcs-1.1.2 or Sun CC does not > > crash. > > Did you try to compile with -fno-strict-aliasing? -fstring-aliasing, > now enabled by default, has caused some problems to packages that use > certain kinds of casts of pointers with undefined results. Thank you very much for your quick reply. No, I didn't try, but I'll try on Monday and report results. By the way, I had a look at the threads on -fstrict-aliasing but could not find a description of the problem. The FAQ reads: The linux kernel violates certain aliasing rules specified in the ANSI/ISO standard. Qt does have quite a few casts of pointers... Which sort of cast could have undefined results? It appears that -fstrict-aliasing does not only break Linux or Qt. You will probably get a lot of traffic about similar problems. So maybe these "aliasing rules" should be explained in the FAQ. By the way, I have a copy of the C++ standard, so if someone can point me to the right paragraph... Thank you, -- Dimitri Papadpoulos From gcc-return-9298-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 16:23:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19774 invoked by alias); 21 Aug 1999 16:23:20 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19758 invoked from network); 21 Aug 1999 16:23:18 -0000 Received: from beech.sucs.soton.ac.uk (152.78.129.138) by egcs.cygnus.com with SMTP; 21 Aug 1999 16:23:18 -0000 Received: from midwife.maths.soton.ac.uk (midwife.maths.soton.ac.uk [152.78.40.148]) by beech.sucs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA03633 for ; Sat, 21 Aug 1999 17:23:16 +0100 (BST) Received: from malone.maths.soton.ac.uk (malone.maths.soton.ac.uk [152.78.40.10]) by midwife.maths.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA10918 for ; Sat, 21 Aug 1999 17:23:15 +0100 (BST) Received: (from jlm@localhost) by malone.maths.soton.ac.uk (8.9.1b+Sun/8.9.1) id RAA18934 for gcc@gcc.gnu.org; Sat, 21 Aug 1999 17:22:22 +0100 (BST) From: Jason Moxham Message-Id: <199908211622.RAA18934@malone.maths.soton.ac.uk> Subject: aliasing To: gcc@gcc.gnu.org Date: Sat, 21 Aug 1999 17:22:22 +0100 (BST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I have a C++ ( really a C prog with a couple of overloaded fn's ) program which I'm fairly sure breaks the strict aliasing rules of Gcc-2.95.1 Where can find a copy of what these rules are , so I can fix my code ? For a temporary fix I added -fno-strict-aliasing to the options and expected a performance drop . However the program now runs 1% faster ??? (I assure you 1% is not a trival amount) Using Slackware 3.9 + gcc 2.95.1 on AMD K6(x86) options -O3 -fno-exceptions -funroll-loops -march=k6 -fomit-frame-pointer -ffast-math ... etc I can send source(100K) + exe's(50K) + data etc.. Jason Moxham jlm@maths.soton.ac.uk From gcc-return-9299-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 16:46:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22303 invoked by alias); 21 Aug 1999 16:46:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22288 invoked from network); 21 Aug 1999 16:46:53 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 21 Aug 1999 16:46:53 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.9.3/8.9.3) with ESMTP id JAA17321; Sat, 21 Aug 1999 09:52:13 -0700 To: jlm@maths.soton.ac.uk Cc: gcc@gcc.gnu.org Subject: Re: aliasing In-Reply-To: <199908211622.RAA18934@malone.maths.soton.ac.uk> References: <199908211622.RAA18934@malone.maths.soton.ac.uk> X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990821095213W.mitchell@codesourcery.com> Date: Sat, 21 Aug 1999 09:52:13 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 51 The relevant paragraph is in [basic.lval] of the C++ standard. The paragraph in the C standard is nearly identical. Here it is. Perhaps someone would like to HTML-ify this, and make a FAQ entry out of it? If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined: --the dynamic type of the object, You can access an object using the type it really has. (I.e., you can use an `int *' to refer to an `int'.) --a cv-qualified version of the dynamic type of the object, You can also use a `const int *' to read an `int'. --a type that is the signed or unsigned type corresponding to the dynamic type of the object, Or an `unsigned int *'. --a type that is the signed or unsigned type corresponding to a cv- qualified version of the dynamic type of the object, Or a `const unsigned int *'. --an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a sub-aggregate or contained union), You can read or write an entire structure, thereby accessing all of its fields. --a type that is a (possibly cv-qualified) base class type of the dynamic type of the object, This one is C++-specific. You can read or write an entire base class of the actual type of the object. --a char or unsigned char type. You can use a `char *', `unsigned char *', `volatile char *', `unsigned const volatile char *', etc. to read or write from anywhere. All pointer types here can be replaced with reference types as well. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-9300-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 17:05:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23823 invoked by alias); 21 Aug 1999 17:05:21 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23808 invoked from network); 21 Aug 1999 17:05:19 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 21 Aug 1999 17:05:19 -0000 Received: from bugshack.cygnus.com (bugshack.cygnus.com [205.180.230.190]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA15434; Sat, 21 Aug 1999 10:05:19 -0700 (PDT) Received: (jsm@localhost) by bugshack.cygnus.com (8.8.7/8.6.4) id KAA01421; Sat, 21 Aug 1999 10:05:19 -0700 Date: Sat, 21 Aug 1999 10:05:18 -0700 From: Jason Molenda To: Gerald Pfeifer Cc: gcc@gcc.gnu.org Subject: Re: Mailserver: DNS Check for From: Message-ID: <19990821100518.A1129@cygnus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7us In-Reply-To: On Sat, Aug 21, 1999 at 11:12:40AM +0200, Gerald Pfeifer wrote: > How about enabling a DNS Check for the From: which is used to send > mail to the egcs/gcc.gnu.org server? > > Replying to asocial guys like the following > From: Chris Rankin > is not possible and frustrating if one does not check carfully enough. Personally, I also find this kind of thing annoying, but I don't think it's something that I (as the site maintainer type dude) am going to dictate to any mailing list. I can understand why some people will do it--like most active people here, I get 5-10 spam notes in my personal mail box a day and they want to avoid that. If the gcc maintainers came to a decision that they wanted to reject this type of header, then I'd be willing to look in to it (or Jeff could). I suspect this issue would be even more contentious than the "Reply-To: set to the whole mailing list" or "[GCC] should be added to Subject: lines" type decisions. I've never found discussions about these issues to be productive--they both just annoy the heck out of some people and their lack of being there annoys others. You just have to leave the decision up to some project owner (or steering committee in the case of gcc) and live with their decision. You could always implement something with a procmail recipe to reject mail with an invalid From:, or put it in a special wankers mail file or something. J From gcc-return-9301-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 17:16:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24819 invoked by alias); 21 Aug 1999 17:16:23 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24804 invoked from network); 21 Aug 1999 17:16:21 -0000 Received: from imo25.mx.aol.com (198.81.17.69) by egcs.cygnus.com with SMTP; 21 Aug 1999 17:16:21 -0000 Received: from N8TM@aol.com by imo25.mx.aol.com (mail_out_v22.4.) id 8JTEa16296 (4155); Sat, 21 Aug 1999 13:15:09 -0400 (EDT) From: N8TM@aol.com Message-ID: Date: Sat, 21 Aug 1999 13:15:09 EDT Subject: Re: Mailserver: DNS Check for From: To: jsm@cygnus.com, pfeifer@dbai.tuwien.ac.at CC: gcc@gcc.gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows sub 15 In a message dated 8/21/99 9:06:33 AM PST, jsm@cygnus.com writes: > If the gcc maintainers came to a decision that they wanted to reject > this type of header, then I'd be willing to look in to it (or Jeff could). What I find more annoying is to spend some time answering a posting with no obvious anti-spam address and then find out that replies are blocked. I'm guessing that no measure taken by the gcc maintainers would solve this, as the gcc site may have been specifically un-blocked by the sender. Tim tprince@computer.org From gcc-return-9302-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 17:46:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28096 invoked by alias); 21 Aug 1999 17:46:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28081 invoked from network); 21 Aug 1999 17:46:31 -0000 Received: from smtp.ucla.edu (HELO serval.noc.ucla.edu) (169.232.10.57) by egcs.cygnus.com with SMTP; 21 Aug 1999 17:46:31 -0000 Received: from cs.ucla.edu (ts24-16.wla.ts.ucla.edu [164.67.20.221]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id KAA11325; Sat, 21 Aug 1999 10:46:26 -0700 (PDT) Message-ID: <37BEE6AA.327FE47F@cs.ucla.edu> Date: Sat, 21 Aug 1999 10:49:30 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: dpo@club-internet.fr, egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, several things: our sysadmin was able to build 2.95.1 on Solaris 2.7 with CC5.0 We can compile and link our code, but it seg faults on trivial code (I posted a ridiculous 4-liner to gcc-bugs), so we are probably going to roll back to 2.95. Earlier, we installed binutils -- when we saw that gcc does not work well with Sun's ld, we decided not to try to fix that. I don't think you can expect to ever link C++ libs compiled with CC and with g++ because they seem to have vastly different ways to process templates (each offer 3-4 options, but non-default options either aren't working on our code, e.g., -frepo or lead to unacceptable code bloat, e.g., w SunCC). So, my question is -- what (how many) patches did you install for CC (you mentioned fully patched) ? 2.95 seemed to work fine on Solaris 2.6 (we upgraded recently to 2.7 and did not try 2.95 here). Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-9303-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 20:44:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6973 invoked by alias); 21 Aug 1999 20:44:20 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6942 invoked from network); 21 Aug 1999 20:44:15 -0000 Received: from 209-249-66-150.snj0.flashcom.net (HELO ocean.lucon.org) (postfix@209.249.66.150) by egcs.cygnus.com with SMTP; 21 Aug 1999 20:44:15 -0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 8C4398EEE; Sat, 21 Aug 1999 13:43:36 -0700 (PDT) Subject: binutils 2.9.5.0.8 is released. To: linux-gcc@vger.rutgers.edu (linuxgcc) Date: Sat, 21 Aug 1999 13:43:36 -0700 (PDT) Cc: egcs@egcs.cygnus.com, libc-hacker@sourceware.cygnus.com (GNU C Library), kjahds@kjahds.com (Kenneth Albanowski), lmfken@lmf.ericsson.se (Kenneth Osterberg), mat@lcs.mit.edu (Mat Hostetter), doughera@lafcol.lafayette.edu (Andy Dougherty), brian@mathworks.com (Brian Bourgault), imp@village.org (Warner Losh), meissner@cygnus.com (Michael Meissner), rfg@monkeys.com (Ron Guilmette), linux-binutils-in@polstra.com (John Polstra), galenh@micron.net (Galen Hazelwood), ralf@informatik.uni-koblenz.de (Ralf Baechle), linas@linas.org (Linas Vepstas), aries@hal2000.terra.vein.hu (Feher Janos) X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990821204336.8C4398EEE@ocean.lucon.org> From: hjl@lucon.org (H.J. Lu) This is the beta release of binutils 2.9.5.0.8 for Linux, which is based on binutils 1999 0821 plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.9.5.0.8 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.5.0.8.tar.gz. Source code. 2. binutils-2.9.5.0.7-2.9.5.0.8.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.5.0.8-1.src.rpm. Source RPM. 4. binutils-2.9.5.0.8-1.i386.rpm. X86 inary RPM for RedHat 6.0. 5. binutils-2.9.5.0.8-1.alpha.rpm. Alpha binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.valinux.com/pub/support/hjl/binutils Thanks. H.J. Lu hjl@lucon.org 08/21/99 From gcc-return-9304-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 21:20:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8888 invoked by alias); 21 Aug 1999 21:20:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8872 invoked from network); 21 Aug 1999 21:20:38 -0000 Received: from gw.varesearch.com (HELO oxygen.su.varesearch.com) (@209.81.8.2) by egcs.cygnus.com with SMTP; 21 Aug 1999 21:20:37 -0000 Received: from hydrogen.su.varesearch.com ([10.1.0.1] helo=varesearch.com) by oxygen.su.varesearch.com with esmtp (Exim 2.12 #6) id 11IIYU-00035B-00; Sat, 21 Aug 1999 14:20:02 -0700 Received: by varesearch.com (Postfix, from userid 561) id 734FF3FC1; Sat, 21 Aug 1999 13:51:16 -0700 (PDT) Subject: gdb 4.17.0.13 is released. To: linux-gcc@vger.rutgers.edu (linuxgcc) Date: Sat, 21 Aug 1999 13:51:16 -0700 (PDT) Cc: egcs@egcs.cygnus.com, libc-hacker@sourceware.cygnus.com (GNU C Library), kjahds@kjahds.com (Kenneth Albanowski), lmfken@lmf.ericsson.se (Kenneth Osterberg), mat@lcs.mit.edu (Mat Hostetter), doughera@lafcol.lafayette.edu (Andy Dougherty), brian@mathworks.com (Brian Bourgault), imp@village.org (Warner Losh), meissner@cygnus.com (Michael Meissner), rfg@monkeys.com (Ron Guilmette), linux-binutils-in@polstra.com (John Polstra), galenh@micron.net (Galen Hazelwood), ralf@informatik.uni-koblenz.de (Ralf Baechle), linas@linas.org (Linas Vepstas) X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990821205116.734FF3FC1@varesearch.com> From: hjl@varesearch.com (H.J. Lu) Hi, Folks, This is the beta release of gdb 4.17.0.13, which is based on gdb 4.17 plus Linux/x86 hardware watchpoint/FPU, glibc 2 pthread and Linux/PPC support. You need linux 2.0.35 or above, or 2.1.xx to get the x86 FPU to work correctly. The Linux/x86 binary works with all recent kernels and C libraries, and the x86 FPU support is enabled at the run-time, depending on the kernel version. You need the latest glibc 2.1.1 to debug LinuxThreads. Special thanks to Dan Bethe who provided the PowePC notebook which makes the LinuxPPC support in gdb possible. Please report any bugs related to gdb 4.17.0.13 to hjl@lucon.org. Problems: Because most of system calls in glibc 2 are written in assembly without frame pointer, gdb may not be able to debug nor get stack trace system calls on glibc-based 2 systems. Due to this, "make check" may fail in FAIL: gdb.base/a1-selftest.exp: backtrace through signal handler FAIL: gdb.base/signals.exp: bt in signals.exp with glibc 2. Also, it is normal to see FAIL: gdb.base/interrupt.exp: continue (timeout) FAIL: gdb.base/interrupt.exp: echo data (timeout) if there is XPASS: gdb.base/interrupt.exp: send_gdb end of file Due to the new cplus-dem.c from gcc 2.95.1, you will get a few FAIL: gdb.c++/demangle.exp: maint demangle __xxxxxxxxxx Changes from gdb 4.17.0.12: 1. Update cplus-dem.c from gcc 2.95.1. Changes from gdb 4.17.0.11: 1. Support LinuxThreads on PowerPC. 2. Support P/III and AMD 3DNow! instructions. 3. Fix debugging dynamically loaded shared object. Changes from gdb 4.17.0.10: 1. Support glibc 2.0 and libc 5. 2. Support LinuxThreads on alpha. 3. Support Solaris 2.7/x86. Changes from gdb 4.17.0.9: 1. Fix support for glibc 2.1 pthread. Need the latest glibc 2.1, newer than 16:30pm PST of 19990-02-03. 2. Fix deleting the hardware watchpoint on x86. Changes from gdb 4.17.0.8: 1. The new cplus-dem.c from egcs 1999-01-12 with a bug fix. 2. Add support for deleting the hardware watchpoint on x86. 3. Update support for glibc 2.1 pthread. 4. Fix C++ testsuite. Changes from gdb 4.17.0.6: 1. Support for glibc 2.1 pthread. But it doesn't work, probably due to the CLONE_PTRACE change to pthread in glibc 2.1. 2. Add support for the older Linux C libraries. 3. Add -static support for glibc 2.1. Changes from gdb 4.17.0.5: 1. Support for glibc 2.0 pthread. It doesn't work with glibc 2.1. 2. The Linux/PPC support. 3. The Linux/Sparc support. Untested. Changes from gdb 4.17.0.4: 1. Fix the Intel FPU tag code handling. Changes from gdb 4.17.0.3: 1. Fix testcases for FPU. 2. Fix x86 hardware watchpoint support. Changes from gdb 4.17.0.2: 1. Fake FP registers on older kernels. Changes from gdb 4.17: 1. Linux/x86 FPU support is added. You can debug floating point numbers just like integers. 2. x86 hardware watchpoint is extended to long long, double and long double. 3. More information on x86 CPU status register. 4. Fix a bug when reading beyond the memory boundary. The file list: 1. gdb-4.17-4.17.0.13.diff.gz. Patch against gdb 4.17. 2. gdb-4.17.0.12-4.17.0.13.diff.gz. Patch against gdb 4.17.0.12. 3. gdb-4.17.0.13.x86.gz. Precompiled Linux/x86 statically linked binary. 4. gdb.spec. A RPM spec file for RedHat 5.x/6.x. The ftp sites for my gdb patches: ftp://ftp.valinux.com/pub/support/hjl/gdb gdb 4.17 source code is available at ftp://ftp.gnu.org/pub/gnu To install the precompiled binary, # gunzp gdb-4.17.0.13.x86.gz # cp gdb-4.17.0.13.x86 /usr/bin/gdb H.J. hjl@gnu.org 08/21/1999 From gcc-return-9305-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 21 23:54:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18402 invoked by alias); 21 Aug 1999 23:54:46 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18387 invoked from network); 21 Aug 1999 23:54:44 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by egcs.cygnus.com with SMTP; 21 Aug 1999 23:54:44 -0000 Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id TAA10412; Sat, 21 Aug 1999 19:54:33 -0400 Received: from rios8.watson.ibm.com (rios8.watson.ibm.com [9.2.229.27]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id TAA08348; Sat, 21 Aug 1999 19:54:33 -0400 Received: from lig32-226-106-215.us.lig-dial.ibm.com by rios8.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA31228; Sat, 21 Aug 1999 19:54:30 -0400 Message-Id: <37BF3B8D.789C8840@watson.ibm.com> Date: Sat, 21 Aug 1999 19:51:41 -0400 From: Michael Gschwind Organization: IBM Research X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: Gerald Pfeifer Cc: gcc@gcc.gnu.org Subject: Re: Mailserver: DNS Check for From: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gerald Pfeifer wrote: > > How about enabling a DNS Check for the From: which is used to send > mail to the egcs/gcc.gnu.org server? > > Replying to asocial guys like the following [line removed] > is not possible and frustrating if one does not check carfully enough. > > Sendmail can do this kind of checks with a single line in the config > files and I am sure that it should also be easy to do with qmail. I can understand why somebody would want to do something like this... Especially in cases where there is also an archive, which any spammer out there can search for the regexp .*@.* In fact, I'm quite hesitant to post to anything that maintains an archive, for exactly that reason -- if you were to do a DNS check, there are still other ways to invalidate the address mike-nospam-@myplace.com From gcc-return-9306-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 01:31:12 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22761 invoked by alias); 22 Aug 1999 01:31:07 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22728 invoked from network); 22 Aug 1999 01:30:59 -0000 Received: from cantva.canterbury.ac.nz (132.181.30.3) by egcs.cygnus.com with SMTP; 22 Aug 1999 01:30:59 -0000 Received: from CONVERSION-DAEMON by its.canterbury.ac.nz (PMDF V5.2-32 #39167) id <01JF2IQVZ8KG8ZF00C@its.canterbury.ac.nz> for gcc@gcc.gnu.org; Sun, 22 Aug 1999 13:30:56 +1200 (NEW ZEALAND STANDARD TIME) Received: from andromeda.elec.canterbury.ac.nz (andromeda.elec.canterbury.ac.nz [132.181.50.31]) by its.canterbury.ac.nz (PMDF V5.2-32 #39167) with ESMTP id <01JF2IQVM1KI8ZF1XA@its.canterbury.ac.nz>; Sun, 22 Aug 1999 13:30:56 +1200 (NEW ZEALAND STANDARD TIME) Received: from ongaonga.elec.canterbury.ac.nz (ongaonga [132.181.54.69]) by andromeda.elec.canterbury.ac.nz (8.9.3/8.9.3) with ESMTP id NAA29927; Sun, 22 Aug 1999 13:30:46 +1200 (NZST) Received: (from mph@localhost) by ongaonga.elec.canterbury.ac.nz (8.9.3/8.9.3) id NAA05352; Sun, 22 Aug 1999 13:30:43 +1200 Date: Sun, 22 Aug 1999 13:30:43 +1200 (NZST) From: Michael Hayes Subject: Re: gcc for C4x In-reply-to: <0056890004864354000002L942*@MHS> To: j.j.f.van.eijck@philips.com Cc: gcc@gcc.gnu.org Message-id: <14271.20762.426141.726295@ongaonga.elec.canterbury.ac.nz> MIME-version: 1.0 (generated by tm-edit 7.108) X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Content-type: text/plain; charset=US-ASCII References: <0056890004864354000002L942*@MHS> j.j.f.van.eijck@philips.com writes: > A few question about gcc-2.95.1 for C4x: > > 1) I'm using binutils-2.7 with a patch from Michael Hayes, but I' m wondering > have the c4x not been included in a later binutils. There is a patch for binutils-2.7 available from www.elec.canterbury.ac.nz/c4x. I do have patches against the latest binutils source tree but there is a small problem I've yet to resolve. There are some nasty hacks in these patches to support the fact that the smallest addressable unit is 32 bits. However, Timothy Wall (twall@tiac.net) is currently tidying up support for TI COFF in the binutils and modifying the BFD stuff to properly handle cases where bits per addressable unit is not 8. > Is their be a patch for gcc-2.95.1 to solve a least the first two points. > I didn't find any changes in Changelog file for C4x between the releases of 2.95 and 2.95.1 Patches to allow parallel instructions and repeat blocks can be also found on www.elec.canterbury.ac.nz/c4x. These patches won't be included in gcc-2.95.1. Michael. From gcc-return-9307-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 01:57:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24554 invoked by alias); 22 Aug 1999 01:57:52 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24539 invoked from network); 22 Aug 1999 01:57:46 -0000 Received: from mail.switchco.com (root@199.190.187.52) by egcs.cygnus.com with SMTP; 22 Aug 1999 01:57:46 -0000 Received: from switchco.com (proteus.swithcho.com [199.190.187.45]) by mail.switchco.com (8.8.0/8.6.12) with ESMTP id UAA32304 for ; Sat, 21 Aug 1999 20:52:43 -0400 Message-ID: <37BF65A6.714FEB1A@switchco.com> Date: Sat, 21 Aug 1999 21:51:18 -0500 From: Benjamin Scherrey Reply-To: scherrey@proteus-tech.com Organization: Proteus Technologies, Inc. X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: egcs mailing list Subject: Problem with auto_prt copy-ctor under last several versions of g++. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is actually a problem that's been around for a little while but I forgot about it until just recently when I installed 2.95.1 on my intel linux system. I've got some code that uses the auto_ptr type defined in the include file 'memory'. My code's a bit too large to be used as a good test case example but the issue is probably apparent to the g++ maintainers (or is this just an STL issue?). At line 37 of the include file 'memory' is a constructor for auto_ptr that takes a non-const auto_ptr&. There is no explicit copy ctor that takes a const auto_ptr&. I've got some code that uses an auto_ptr in a map indexed by an int. I know this can result in unintended consequences but the usage is very controlled from an external interface. Anyway, the error I get complains about conversion from a 'const auto_ptr< Type >' to an 'auto_ptr< Type >&' discarding qualifiers (correctly so). My fix was to simply change the constructor to take a const reference rather than the non-const ref. My code now builds and runs correctly with no errors or warnings. Is this strictly a bug in the memory include file? Was this constructor intended to be *the* copy constructor or is there really supposed to be another constructor in addition to the copy constructor (which the code writer probably [incorrectly?] assumed would then be automatically generated by the compiler)? Appreciate comments, questions, and some kind of "fix" for the next release. Ben Scherrey From gcc-return-9308-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 02:11:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27040 invoked by alias); 22 Aug 1999 02:11:44 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27025 invoked from network); 22 Aug 1999 02:11:39 -0000 Received: from korrigan.inria.fr (138.96.48.27) by egcs.cygnus.com with SMTP; 22 Aug 1999 02:11:39 -0000 Received: by korrigan.inria.fr (8.8.8/8.8.5) id EAA03800; Sun, 22 Aug 1999 04:11:34 +0200 (MET DST) To: scherrey@proteus-tech.com Cc: egcs mailing list Subject: Re: Problem with auto_prt copy-ctor under last several versions of g++. References: <37BF65A6.714FEB1A@switchco.com> From: Gabriel Dos_Reis In-Reply-To: Benjamin Scherrey's message of "Sat, 21 Aug 1999 21:51:18 -0500" Organization: I.N.R.I.A Sophia-Antipolis (France) Date: 22 Aug 1999 04:11:33 +0200 Message-ID: Lines: 18 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Benjamin Scherrey writes: | This is actually a problem that's been around for a little while but I | forgot about it until just recently when I installed 2.95.1 on my | intel linux system. I've got some code that uses the auto_ptr type | defined in the include file 'memory'. My code's a bit too large to be | used as a good test case example but the issue is probably apparent to | the g++ maintainers (or is this just an STL issue?). | | At line 37 of the include file 'memory' is a constructor for auto_ptr | that takes a non-const auto_ptr&. There is no explicit copy ctor that | takes a const auto_ptr&. Well, this is a C++ specific issue. autor_ptr is designed on purpose to not be CopyConstructible nor Assignable; hence you can't put it in a container and expect any reasonable behaviour. -- Gaby From gcc-return-9309-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 02:42:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30942 invoked by alias); 22 Aug 1999 02:42:54 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30927 invoked from network); 22 Aug 1999 02:42:52 -0000 Received: from mail.switchco.com (root@199.190.187.52) by egcs.cygnus.com with SMTP; 22 Aug 1999 02:42:52 -0000 Received: from switchco.com (proteus.swithcho.com [199.190.187.45]) by mail.switchco.com (8.8.0/8.6.12) with ESMTP id VAA32355; Sat, 21 Aug 1999 21:29:30 -0400 Message-ID: <37BF6E46.60391DC6@switchco.com> Date: Sat, 21 Aug 1999 22:28:06 -0500 From: Benjamin Scherrey Reply-To: scherrey@proteus-tech.com Organization: Proteus Technologies, Inc. X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gabriel Dos_Reis CC: egcs mailing list Subject: Re: Problem with auto_prt copy-ctor under last several versions of g++. References: <37BF65A6.714FEB1A@switchco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Darn - this is a pain. I guess I'll have to drop the auto_ptr in my code. Meanwhile, shouldn't there be an explicit private declaration of the copy constructor and assignment operators in order to make this disallowment more clear. Also, what is the purpose of having a constructor that takes a non-const instance if copy constructors are supposed to be illegal? thanx & later, Ben Scherrey Gabriel Dos_Reis wrote: > > Benjamin Scherrey writes: > > | This is actually a problem that's been around for a little while but I > | forgot about it until just recently when I installed 2.95.1 on my > | intel linux system. I've got some code that uses the auto_ptr type > | defined in the include file 'memory'. My code's a bit too large to be > | used as a good test case example but the issue is probably apparent to > | the g++ maintainers (or is this just an STL issue?). > | > | At line 37 of the include file 'memory' is a constructor for auto_ptr > | that takes a non-const auto_ptr&. There is no explicit copy ctor that > | takes a const auto_ptr&. > > Well, this is a C++ specific issue. autor_ptr is designed on > purpose to not be CopyConstructible nor Assignable; hence you can't > put it in a container and expect any reasonable behaviour. > > -- Gaby From gcc-return-9310-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 02:56:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32275 invoked by alias); 22 Aug 1999 02:56:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32260 invoked from network); 22 Aug 1999 02:56:30 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 22 Aug 1999 02:56:30 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id TAA28486; Sat, 21 Aug 1999 19:56:21 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id TAA22428; Sat, 21 Aug 1999 19:56:20 -0700 To: Jan Hubicka Cc: Alexandre Oliva , egcs@egcs.cygnus.com Subject: Re: Yet another function attribute? References: <19990820221536.48077@atrey.karlin.mff.cuni.cz> <19990821055414.40740@atrey.karlin.mff.cuni.cz> From: Jason Merrill Date: 21 Aug 1999 19:56:20 -0700 In-Reply-To: Jan Hubicka's message of "Sat, 21 Aug 1999 05:54:14 +0200" Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Jan Hubicka writes: > While implementing it (I am just doing last checks for first part of > patch to handle such functions and detect them automatically) > I found that it match closely "side_effects" attribute in gcc. > So maybe "noside_effects" can be good name. But it does not represent > the fact, that function also must be deterministics, so possibly > someone will tend to add "noside_effects" to functions like inport, > where it is wrong. inport has side effects; reading from a volatile lvalue is a side effect. Jason From gcc-return-9311-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 04:22:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3193 invoked by alias); 22 Aug 1999 04:22:42 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3178 invoked from network); 22 Aug 1999 04:22:40 -0000 Received: from korrigan.inria.fr (138.96.48.27) by egcs.cygnus.com with SMTP; 22 Aug 1999 04:22:40 -0000 Received: by korrigan.inria.fr (8.8.8/8.8.5) id GAA04518; Sun, 22 Aug 1999 06:22:36 +0200 (MET DST) To: scherrey@proteus-tech.com Cc: Gabriel Dos_Reis , egcs mailing list Subject: Re: Problem with auto_prt copy-ctor under last several versions of g++. References: <37BF65A6.714FEB1A@switchco.com> <37BF6E46.60391DC6@switchco.com> From: Gabriel Dos_Reis In-Reply-To: Benjamin Scherrey's message of "Sat, 21 Aug 1999 22:28:06 -0500" Organization: I.N.R.I.A Sophia-Antipolis (France) Date: 22 Aug 1999 06:22:35 +0200 Message-ID: Lines: 23 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Benjamin Scherrey writes: | Darn - this is a pain. I guess I'll have to drop the auto_ptr in my | code. Meanwhile, shouldn't there be an explicit private declaration of | the copy constructor and assignment operators in order to make this | disallowment more clear. Why??? The C++ definition does define them public. GCC is following the Standard. | ... Also, what is the purpose of having a | constructor that takes a non-const instance if copy constructors are | supposed to be illegal? Not being CopyConstructible isn't equivalent to having private copy constructor. Furthermore having a copy constructor taking a non-const reference makes it sure that temporaries are not copiable. If your point is that auto_ptr is useless, please consider news:comp.std.c++ -- Gaby From gcc-return-9312-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 05:58:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8214 invoked by alias); 22 Aug 1999 05:58:30 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8182 invoked from network); 22 Aug 1999 05:58:25 -0000 Received: from d12lmsgate.de.ibm.com (HELO d12lmsgate) (195.212.91.199) by egcs.cygnus.com with SMTP; 22 Aug 1999 05:58:25 -0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate (1.0.0) with ESMTP id HAA17330; Sun, 22 Aug 1999 07:54:45 +0200 From: veksler@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.7m1/NCO v2.04) with SMTP id HAA37904; Sun, 22 Aug 1999 07:57:45 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id C12567D5.0020BEAB ; Sun, 22 Aug 1999 07:57:39 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: Franz Sirl cc: Joern Rennecke , dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com Message-ID: Date: Sun, 22 Aug 1999 08:57:33 +0300 Subject: Re: Deadly optimization bug (all gcc versions!) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Am Mit, 18 Aug 1999 schrieb Franz Sirl: > Well, this is the analysis, however I have no idea how to fix it correctly :-(. > A local fix in if_then_else_cond() would be to compare the results of > nonzero_bits(x), reg_nonzero_bits[REGNO(x)] and > reg_last_set_nonzero_bits[REGNO(x)] and use the biggest one? But this may > just hide other potential problems with get_last_value()? Is there anyone trying to fix this? If not, I suppose this bug & analysis should enter some TODO list on gcc & egcs. It should be fixed for: gcc-2.7.2.4 (what is the latest patch version ?) gcc-2.95.2 egcs - current. I could look into it myself, but that would take me a lot of time to learn RTL, and understand all sort of internal gcc issues (which I would like to avoid). Besides, it's hard to believe that a bug of this magnitude does not interest people that do understand what's going on inside gcc. Thanks Michael From gcc-return-9313-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 09:17:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20344 invoked by alias); 22 Aug 1999 09:17:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20328 invoked from network); 22 Aug 1999 09:17:42 -0000 Received: from pele.santafe.edu (192.12.12.119) by egcs.cygnus.com with SMTP; 22 Aug 1999 09:17:42 -0000 Received: from wijiji.santafe.edu (wijiji [192.12.12.5]) by pele.santafe.edu (8.9.1/8.9.1) with ESMTP id DAA00127 for ; Sun, 22 Aug 1999 03:17:40 -0600 (MDT) Received: (from rms@localhost) by wijiji.santafe.edu (8.9.1b+Sun/8.9.1) id DAA01485; Sun, 22 Aug 1999 03:17:40 -0600 (MDT) Date: Sun, 22 Aug 1999 03:17:40 -0600 (MDT) Message-Id: <199908220917.DAA01485@wijiji.santafe.edu> X-Authentication-Warning: wijiji.santafe.edu: rms set sender to rms@gnu.org using -f From: Richard Stallman To: gcc@gcc.gnu.org Subject: gcc --help Reply-to: rms@gnu.org I tried `gcc --help' in GCC 2.7.2.3, which is what's installed here, and instead of printing help, it gave an error that there were no input files. If the current version still does that, I think it should be fixed to print the help message instead. From gcc-return-9314-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 09:39:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22059 invoked by alias); 22 Aug 1999 09:39:14 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22024 invoked from network); 22 Aug 1999 09:38:54 -0000 Received: from adsl-216-101-162-242.dsl.snfc21.pacbell.net (HELO pizda.davem.net) (root@216.101.162.242) by egcs.cygnus.com with SMTP; 22 Aug 1999 09:38:52 -0000 Received: (from davem@localhost) by pizda.davem.net (8.9.3/8.9.3) id CAA01332; Sun, 22 Aug 1999 02:39:00 -0700 Date: Sun, 22 Aug 1999 02:39:00 -0700 Message-Id: <199908220939.CAA01332@pizda.davem.net> X-Authentication-Warning: pizda.davem.net: davem set sender to davem@redhat.com using -f From: "David S. Miller" To: rms@gnu.org CC: gcc@gcc.gnu.org In-reply-to: <199908220917.DAA01485@wijiji.santafe.edu> (message from Richard Stallman on Sun, 22 Aug 1999 03:17:40 -0600 (MDT)) Subject: Re: gcc --help References: <199908220917.DAA01485@wijiji.santafe.edu> Date: Sun, 22 Aug 1999 03:17:40 -0600 (MDT) From: Richard Stallman I tried `gcc --help' in GCC 2.7.2.3, which is what's installed here, and instead of printing help, it gave an error that there were no input files. If the current version still does that, I think it should be fixed to print the help message instead. The current version is fixed, and behaves in the way you suggest, 'gcc --help' prints the help instead of an error. Later, David S. Miller davem@redhat.com From gcc-return-9315-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 10:51:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30119 invoked by alias); 22 Aug 1999 10:50:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30104 invoked from network); 22 Aug 1999 10:50:56 -0000 Received: from front3.grolier.fr (194.158.96.53) by egcs.cygnus.com with SMTP; 22 Aug 1999 10:50:55 -0000 Received: from dimitri.localdomain (ppp-170-56.villette.club-internet.fr [195.36.170.56]) by front3.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA03102; Sun, 22 Aug 1999 12:50:51 +0200 (MET DST) Received: from club-internet.fr (dimitri.localdomain [127.0.0.1]) by dimitri.localdomain (8.8.7/8.8.7/Dimitri) with ESMTP id MAA00591; Sun, 22 Aug 1999 12:45:20 +0200 Message-ID: <37BFD4C0.3B3A6261@club-internet.fr> Date: Sun, 22 Aug 1999 12:45:20 +0200 From: Dimitri Papadopoulos X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: Igor Markov CC: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <37BEE6AA.327FE47F@cs.ucla.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Igor Markov wrote: > > Dimitri, > > several things: > our sysadmin was able to build 2.95.1 on Solaris 2.7 with CC5.0 > We can compile and link our code, but it seg faults on trivial > code (I posted a ridiculous 4-liner to gcc-bugs), so we are > probably going to roll back to 2.95. I don't get segfaults with your 4-liner. The cause may well be that you are mixing Sun as/ld when buidling GCC and GNU as/ld when building your programs which has caused me a lot of trouble... I had exactly the same problems. This one wouldn't even link: cout << endl; Otherwise, I was able to build GCC with EGCS for use with GNU as/ld _and_ Sun as/ld. However it took me a few days of tests and modifications. I still don't understand why a build works or not. It depends on many factors: - GNU as/ld are in the PATH or not when buidling GCC. - Sun as/ld are in the PATH or not when buidling GCC. - The compiler used to bootstrap internally uses GNU as/ld or not (this is relevant for EGCS/GCC compilers only, for they may use GNU as/ld without as/ld being in the PATH). - GNU as/ld are in the PATH or not when using GCC. - Sun as/ld are in the PATH or not when using GCC. I don't have time to test all combinations. > Earlier, we installed binutils -- when we saw that gcc does not > work well with Sun's ld, we decided not to try to fix that. That's not an option for me. There are people out there who use EGCS with Sun as/ld and I want to be able to exchange shared objects with them. It's really a problem that EGCS/GCC produce their own format of shared objects on Solaris, instead of sticking to the Solaris standard format. > I don't think you can expect to ever link C++ libs compiled with > CC and with g++ because they seem to have vastly different ways > to process templates (each offer 3-4 options, but non-default > options either aren't working on our code, e.g., -frepo or lead > to unacceptable code bloat, e.g., w SunCC). Of course I don't expect C++ programs compiled by different compilers to interoperate. That's not even a question of templates. I have never written that I expect CC and g++ to interoperate. > So, my question is -- what (how many) patches did you install for CC > (you mentioned fully patched) ? I have installed all the Workshop patches recommended by Sun: http://access1.sun.com/workshop/current-patches.html These are server patches for building 32-bits programs 107289-03 107295-01 107311-05 107354-01 107355-02 107357-03 107740-01 107742-01 server patches for building 64-bits programs 107358-02 107390-04 Solaris 7 client patches for building and running 32-bits programs 106327-05 106748-02 Solaris 7 client patches for building and running 64-bits programs 106300-06 107058-01 Note that their C++ front-end is badly broken even after adding all these patches... > 2.95 seemed to work fine on Solaris 2.6 (we upgraded recently to 2.7 > and did not try 2.95 here). All software seem to work fine until you have problems... After a few days struggling to install it, the compiler seemed to work fine indeed, until I started getting segfaults in Qt, which works like a charm with EGCS, with other compilers or on other platforms. The problem may well be that I must use -fno-strict-aliasing as Alexandre Oliva pointed out. Dimitri From gcc-return-9316-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 11:04:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31804 invoked by alias); 22 Aug 1999 11:04:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31772 invoked from network); 22 Aug 1999 11:04:05 -0000 Received: from linuxpc1.lauterbach.com (qmailr@194.195.165.177) by egcs.cygnus.com with SMTP; 22 Aug 1999 11:04:05 -0000 Received: (qmail 31991 invoked from network); 22 Aug 1999 11:04:00 -0000 Received: from ns1223.munich.netsurf.de (HELO ns1102.munich.netsurf.de) (195.180.235.223) by linuxpc1 with SMTP; 22 Aug 1999 11:04:00 -0000 From: Franz Sirl To: veksler@il.ibm.com Subject: Re: Deadly optimization bug (all gcc versions!) Date: Sun, 22 Aug 1999 12:53:12 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: Joern Rennecke , dje@watson.ibm.com, gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org References: In-Reply-To: MIME-Version: 1.0 Message-Id: <99082213044400.00461@ns1102.munich.netsurf.de> Content-Transfer-Encoding: 8bit Am Son, 22 Aug 1999 schrieb veksler@il.ibm.com: >Am Mit, 18 Aug 1999 schrieb Franz Sirl: >> Well, this is the analysis, however I have no idea how to fix it >correctly :-(. >> A local fix in if_then_else_cond() would be to compare the results of >> nonzero_bits(x), reg_nonzero_bits[REGNO(x)] and >> reg_last_set_nonzero_bits[REGNO(x)] and use the biggest one? But this may >> just hide other potential problems with get_last_value()? > >Is there anyone trying to fix this? If not, I suppose this bug & analysis >should enter >some TODO list on gcc & egcs. It should be fixed for: > gcc-2.7.2.4 (what is the latest patch version ?) > gcc-2.95.2 > egcs - current. > >I could look into it myself, but that would take me a lot of time to learn >RTL, and >understand all sort of internal gcc issues (which I would like to avoid). >Besides, it's >hard to believe that a bug of this magnitude does not interest people that >do understand > what's going on inside gcc. Well a simple fix is not the problem :-). The appended patch solves your testcase, I just don't know if it goes far enough. Someone with more knowledge about combine should look carefully at the optimization in get_last_value() causing this. Does this optimization possibly cause other problems? Is this optimization worth the trouble anyway? Franz. Index: combine.c =================================================================== RCS file: /egcs/carton/cvsfiles/egcs/gcc/combine.c,v retrieving revision 1.68 diff -u -p -r1.68 combine.c --- combine.c 1999/08/20 23:05:06 1.68 +++ combine.c 1999/08/22 10:41:29 @@ -7529,7 +7529,10 @@ nonzero_bits (x, mode) tem = get_last_value (x); - if (tem) + /* disable this code since get_last_value might return the last + value set before the substitution chain, which might have + differing nonzero_bits. */ + if (0 && tem) { #ifdef SHORT_IMMEDIATES_SIGN_EXTEND /* If X is narrower than MODE and TEM is a non-negative --- /dev/null Tue May 5 15:32:27 1998 +++ 19990822.c Sun Aug 22 05:46:13 1999 @@ -0,0 +1,19 @@ +/* testcase provided by veksler@il.ibm.com */ + +/* If one=1, then the output should be: bit&1 */ +unsigned test(unsigned one , unsigned bit) +{ + unsigned val= bit & 1; + unsigned zero= one >> 1; + + val++; + return zero + ( val>> 1 ); +} + +int main() +{ + if (test(1,0) != 0) abort(); + if (test(1,1) != 1) abort(); + if (test(1,65535) != 1) abort(); + exit(0); +} From gcc-return-9317-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 14:38:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 742 invoked by alias); 22 Aug 1999 14:38:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 726 invoked from network); 22 Aug 1999 14:38:54 -0000 Received: from ss1000.ms.mff.cuni.cz (root@195.113.19.221) by egcs.cygnus.com with SMTP; 22 Aug 1999 14:38:54 -0000 Received: from u-sl0.ms.mff.cuni.cz (IDENT:jhub6202@u-sl0.ms.mff.cuni.cz [195.113.16.50]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id QAA20595 for ; Sun, 22 Aug 1999 16:38:51 +0200 Received: from localhost (jhub6202@localhost) by u-sl0.ms.mff.cuni.cz (8.8.8/8.8.8) with SMTP id QAA31619 for ; Sun, 22 Aug 1999 16:38:51 +0200 X-Authentication-Warning: u-sl0.ms.mff.cuni.cz: jhub6202 owned process doing -bs Date: Sun, 22 Aug 1999 16:38:50 +0200 (MET DST) From: Jan Hubicka X-Sender: jhub6202@u-sl0.ms.mff.cuni.cz To: egcs@egcs.cygnus.com Subject: New const function detection code and infinite loops. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi It is OK to remove call to function containing infinite loop? I don't think so, but thats what current gcc does when function is detected constant. I've already implemented code to prove finitarity of function by doing topological sort on flowgraph. This is very conservative, but disable only about 1/3 of pure functions detected in gcc. So I can send a patch if neccesary. Is there any way how to detect bounded loops? (loop.c does it, is this information available somewhere?) Also how can I detect recursive calls of function to itself? (I can possibly use symbol ref field in mem, but can't it be hidden by CSE?) This can help me to futher improve the detection code. Honza From gcc-return-9318-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 14:58:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2856 invoked by alias); 22 Aug 1999 14:58:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2841 invoked from network); 22 Aug 1999 14:58:43 -0000 Received: from ss1000.ms.mff.cuni.cz (root@195.113.19.221) by egcs.cygnus.com with SMTP; 22 Aug 1999 14:58:43 -0000 Received: from u-sl0.ms.mff.cuni.cz (IDENT:jhub6202@u-sl0.ms.mff.cuni.cz [195.113.16.50]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id QAA31392 for ; Sun, 22 Aug 1999 16:58:41 +0200 Received: from localhost (jhub6202@localhost) by u-sl0.ms.mff.cuni.cz (8.8.8/8.8.8) with SMTP id QAA32242 for ; Sun, 22 Aug 1999 16:58:40 +0200 X-Authentication-Warning: u-sl0.ms.mff.cuni.cz: jhub6202 owned process doing -bs Date: Sun, 22 Aug 1999 16:58:40 +0200 (MET DST) From: Jan Hubicka X-Sender: jhub6202@u-sl0.ms.mff.cuni.cz To: egcs@egcs.cygnus.com Subject: Const function detection and public functions. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi According to the Jeff's comment, that public functions may get overwritten for shared libraries, the detection is now disabled for them. But there is at least one other place in the compiler that violates this - the inlining of functions. So perhaps to be consistent and we may re-enable the detection or disable the inlining... Honza From gcc-return-9319-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 15:32:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5678 invoked by alias); 22 Aug 1999 15:32:35 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5663 invoked from network); 22 Aug 1999 15:32:32 -0000 Received: from sapin.irfu.se (jb@130.238.30.18) by egcs.cygnus.com with SMTP; 22 Aug 1999 15:32:32 -0000 Received: (from jb@localhost) by sapin.irfu.se (8.8.6 (PHNE_16852)/8.8.6) id RAA29293; Sun, 22 Aug 1999 17:32:28 +0200 (METDST) Date: Sun, 22 Aug 1999 17:32:28 +0200 (METDST) From: Jan Bergman Message-Id: <199908221532.RAA29293@sapin.irfu.se> To: gcc@gcc.gnu.org Subject: gcc-2.95.1 Success Cc: jb@irfu.se Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: kPxlfobXZpk0meeq/WiySw== Hi, I've just installed gcc-2.95.1 on my HP9000/715 running HP-UX 11.00. Output from config.guess: hppa1.1-hp-hpux11.00 The build failed using the HP ANSI C compiler (it worked on a HP9000/782 running HP-UX 10.20 though, hppa2.0-hp-hpux10.20). I resorted to the old egcs compiler, egcs-2.91.66, which did the job without any trouble whatsoever. I used GNU make (make-3.77) and GNU as (binutils-2.9.1) during the build. Regards, Jan Bergman, Swedish Institute of Space Physics, Uppsala Division, jb@irfu.se From gcc-return-9320-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 15:45:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8369 invoked by alias); 22 Aug 1999 15:45:11 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8351 invoked from network); 22 Aug 1999 15:45:08 -0000 Received: from cheetah.spots.ab.ca (209.115.174.2) by egcs.cygnus.com with SMTP; 22 Aug 1999 15:45:08 -0000 Received: from primary (pm3-133.spots.ab.ca [209.115.174.112]) by cheetah.spots.ab.ca (8.9.3/8.9.3) with SMTP id JAA01670 for ; Sun, 22 Aug 1999 09:45:06 -0600 Message-Id: <199908221545.JAA01670@cheetah.spots.ab.ca> From: "edA-qa mort-ora-y" Organization: dis-Emi-A To: gcc@gcc.gnu.org Date: Sun, 22 Aug 1999 09:38:36 -0600 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: How is 'this' passed to member function calls? Reply-to: edA-qa@disemia.com Priority: normal X-mailer: Pegasus Mail for Win32 (v3.01b) I have a situation where I want to directly call member functions, via a pointer to the member function and having an object pointer. The only trouble is that I don't know the type of class, I only know the signature of the function. That is, I'm sort of calling the function blind. Obviously this is an optimization of the code, since it can be done another way, but it'd be a great optimization. But I need to know whether there is a consistant manner in which the object ptr 'this' is passed on the stack. In Win32 there is a common format due to COM, but does GCC have a common format on other operating systems? -- edA-qa mort-ora-y From gcc-return-9321-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 15:50:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10833 invoked by alias); 22 Aug 1999 15:50:09 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10787 invoked from network); 22 Aug 1999 15:50:05 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 22 Aug 1999 15:50:05 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id MAA19832; Sun, 22 Aug 1999 12:46:02 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id MAA08162; Sun, 22 Aug 1999 12:46:01 -0300 (EST) To: Dimitri Papadopoulos Cc: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <3780F13B.3BCE13F8@club-internet.fr> <826729mktv.fsf@lexx.idonex.se> <37BEC99E.9BCE3572@club-internet.fr> <37BED06C.954DEC9F@club-internet.fr> From: Alexandre Oliva Date: 22 Aug 1999 12:49:56 -0300 In-Reply-To: Dimitri Papadopoulos's message of "Sat, 21 Aug 1999 18:14:36 +0200" Message-ID: Lines: 14 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 21, 1999, Dimitri Papadopoulos wrote: > By the way, I had a look at the threads on -fstrict-aliasing but could > not find a description of the problem. Mark Mitchell has posted a message to this mailing list with subject ``Re: aliasing'', a few hours ago, that describes the rules in enough(?) detail. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9322-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 15:52:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12177 invoked by alias); 22 Aug 1999 15:52:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12155 invoked from network); 22 Aug 1999 15:52:56 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 22 Aug 1999 15:52:56 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id MAA19855; Sun, 22 Aug 1999 12:48:43 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id MAA08211; Sun, 22 Aug 1999 12:48:41 -0300 (EST) To: N8TM@aol.com Cc: jsm@cygnus.com, pfeifer@dbai.tuwien.ac.at, gcc@gcc.gnu.org Subject: Re: Mailserver: DNS Check for From: References: From: Alexandre Oliva Date: 22 Aug 1999 12:52:36 -0300 In-Reply-To: N8TM@aol.com's message of "Sat, 21 Aug 1999 13:15:09 EDT" Message-ID: Lines: 22 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 21, 1999, N8TM@aol.com wrote: > In a message dated 8/21/99 9:06:33 AM PST, jsm@cygnus.com writes: >> If the gcc maintainers came to a decision that they wanted to reject >> this type of header, then I'd be willing to look in to it (or Jeff could). > What I find more annoying is to spend some time answering a posting with no > obvious anti-spam address and then find out that replies are blocked. I'm > guessing that no measure taken by the gcc maintainers would solve this, as > the gcc site may have been specifically un-blocked by the sender. I dislike when I get such a delivery error too, but the fact that a copy of the message went to the GCC mailing list means the time spent on the reply was not wasted. It's just that the original poster will only get it if he subscribes the list or reads the archives, but others may benefit from the reply as well. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9323-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 16:02:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15819 invoked by alias); 22 Aug 1999 16:02:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15804 invoked from network); 22 Aug 1999 16:02:33 -0000 Received: from imo28.mx.aol.com (198.81.17.72) by egcs.cygnus.com with SMTP; 22 Aug 1999 16:02:33 -0000 Received: from N8TM@aol.com by imo28.mx.aol.com (mail_out_v22.4.) id 1BAOa22756 (4191); Sun, 22 Aug 1999 12:00:51 -0400 (EDT) From: N8TM@aol.com Message-ID: <84b851b3.24f178b2@aol.com> Date: Sun, 22 Aug 1999 12:00:50 EDT Subject: Re: Mailserver: DNS Check for From: To: oliva@dcc.unicamp.br CC: jsm@cygnus.com, pfeifer@dbai.tuwien.ac.at, gcc@gcc.gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows sub 15 In a message dated 8/22/99 7:52:47 AM PST, oliva@dcc.unicamp.br writes: > the fact that a > copy of the message went to the GCC mailing list means the time spent > on the reply was not wasted. On some of these messages, I try to make an individual reply as the subject is sufficiently off topic to annoy the list members. Tim From gcc-return-9324-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 18:46:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32611 invoked by alias); 22 Aug 1999 18:46:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32596 invoked from network); 22 Aug 1999 18:45:57 -0000 Received: from linux01.gwdg.de (root@134.76.13.21) by egcs.cygnus.com with SMTP; 22 Aug 1999 18:45:57 -0000 Received: from RAS23-015.gwdg.de (RAS23-015.gwdg.de [134.76.23.15]) by linux01.gwdg.de (8.9.3/8.9.3) with SMTP id UAA23388; Sun, 22 Aug 1999 20:46:09 +0200 From: pthomas@suse.de (Philipp Thomas) To: Sebastien Loisel Cc: gcc@gcc.gnu.org Subject: Re: Bounds Checking Date: Sun, 22 Aug 1999 18:45:31 GMT Organization: SuSE GmbH Message-ID: <37d643cb.147661378@linux01.gwdg.de> References: In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Tue, 17 Aug 1999 16:24:23 -0700 (PDT), Sebastien Loisel wrote: >other hacks which were less clear to me. I would like to point out that = Richard=20 >Jones and Paul Kelly a long time ago (1995) released patches for gcc = 2.7.0 (and=20 >then to 2.7.1 and 2.7.2) Yes, I know. I contacted Richard and some months ago he notified me that = he had finally got all that was needed to assign that work to the FSF done.=20 Someone from Belgium (Herman ten Brugge, if I remember correctly) has already ported those patches to egcs and last I read he is porting those patches to gcc 2.95. If you search the archives you will find his mail (I don't have his email address) and maybe you would like to contact him directly. --=20 Philipp Thomas SuSE GmbH phone +49-911-3247130 pthomas@suse.de Schanzaeckerstr. 10 fax +49-911-3206727 http://www.suse.de D-90443 Nuremberg, Germany From gcc-return-9325-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 20:27:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4947 invoked by alias); 22 Aug 1999 20:27:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4930 invoked from network); 22 Aug 1999 20:27:50 -0000 Received: from mail-ffm-p.arcor-ip.de (HELO mail.arcor-ip.de) (145.253.2.10) by egcs.cygnus.com with SMTP; 22 Aug 1999 20:27:50 -0000 Received: from hallo.hey (145.253.112.20) by mail.arcor-ip.de; 22 Aug 1999 22:27:23 +0200 Received: from localhost (localhost [[UNIX: localhost]]) by hallo.hey (8.8.8/8.8.8) id VAA00817; Sun, 22 Aug 1999 21:21:22 +0200 From: Hartmut Schirmer Reply-To: hartmut.schirmer@arcormail.de To: Jan Hubicka Subject: Re: Const function detection and public functions. Date: Sun, 22 Aug 1999 21:19:06 +0200 X-Mailer: KMail [version 0.7.9] Content-Type: text/plain References: Cc: egcs@egcs.cygnus.com MIME-Version: 1.0 Message-Id: <99082221212102.00705@hallo> Content-Transfer-Encoding: 8bit On Sun, 22 Aug 1999, you wrote: >Hi >According to the Jeff's comment, that public functions may get overwritten >for shared libraries, the detection is now disabled for them. Could you make this switchable on the command line? Some systems don´t have shared libs and could benefit from this Thanks, Hartmut From gcc-return-9326-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 21:44:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11124 invoked by alias); 22 Aug 1999 21:44:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11109 invoked from network); 22 Aug 1999 21:44:26 -0000 Received: from tele-post-20.mail.demon.net (194.217.242.20) by egcs.cygnus.com with SMTP; 22 Aug 1999 21:44:26 -0000 Received: from tazenda.demon.co.uk ([158.152.220.239] helo=kings-cross.london.uk.eu.org) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 11IfPc-000KdM-0K for gcc@gcc.gnu.org; Sun, 22 Aug 1999 21:44:24 +0000 Received: from localhost ([127.0.0.1] helo=kings-cross.london.uk.eu.org ident=phil) by kings-cross.london.uk.eu.org with esmtp (Exim 2.05 #1) id 11IetQ-0000yp-00 for gcc@gcc.gnu.org; Sun, 22 Aug 1999 22:11:08 +0100 X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: gcc@gcc.gnu.org Subject: Re: Cross Compiling In-Reply-To: Message from Daniel Jacobowitz of "Mon, 16 Aug 1999 21:45:30 EDT." <19990816214530.A2623@them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Aug 1999 22:11:08 +0100 From: Philip Blundell Message-Id: >Hm, but is it possible to build a target C compiler without a target >libiberty (obviously you'd need a host libiberty but that isn't a >problem)? Yes. You can, in extremis, bootstrap a system in a piecemeal fashion if you don't have any prebuilt libraries available. p. From gcc-return-9327-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 23:31:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21463 invoked by alias); 22 Aug 1999 23:31:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21436 invoked from network); 22 Aug 1999 23:31:47 -0000 Received: from monsoon.newjersey.sco.com (132.147.103.53) by egcs.cygnus.com with SMTP; 22 Aug 1999 23:31:47 -0000 Received: from co.com ([207.65.231.166]) by monsoon.newjersey.sco.com (8.8.7/UW7.0.1) with ESMTP id TAA06960; Sun, 22 Aug 1999 19:31:41 -0400 (EDT) Received: (from robertl@localhost) by co.com (8.8.7/8.8.7) id RAA00399; Fri, 20 Aug 1999 17:47:13 -0500 Date: Fri, 20 Aug 1999 17:47:12 -0500 From: Robert Lipe To: Rob Kramer Cc: egcs@egcs.cygnus.com Subject: Re: SCO 5.0.2 signal 11 + exceptions problem.. Message-ID: <19990820174712.A370@rjlaptop.sco.com> References: <37BD2C7D.1D80@singnet.com.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.15i In-Reply-To: <37BD2C7D.1D80@singnet.com.sg>; from Rob Kramer on Fri, Aug 20, 1999 at 06:22:53PM +0800 Rob Kramer wrote: > I tried building GCC 2.95 for SCO OSR v3.2 5.0.2, and got a 'fatal > signal > 11 in as' somewhere along the build (while compiling 'exception.c'). There is a bug in the 5.0.0 and 5.0.2 assemblers that gets triggered on 2.95 when building this file. Shortly before SCO Forum, a TLS was submitted to the queue to provide a fixed assembler for these hosts. Since I'm on an airplane right now, I can't check ftp.sco.com/TLS to see if it was propagated. I would be pleasantly suprised if it was; the reality is that such things tend to take a back seat to the show. I have annoyed the responsible party and after the Forum backlog clears this should surface. If you don't see it within a week or two, feel free to bang my gong. > Sigh. This looks like my build is broken because of the signal 11 in > exception.c? I'm using egcs 1.1.1 incapable of RTTI to bootstrap. Should This is an artifact of the assembler being hosed. You're missing key files from the archives. > Wonder if GNU as would get that signal too.. As mentioned in specific.html, GNU as involves several tradeoffs on this host. Be sure you're willing to pay the price before proceeding on those grounds. Waiting for the TLS is surely the thing to do. RJL From gcc-return-9328-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 23:55:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25237 invoked by alias); 22 Aug 1999 23:55:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25219 invoked from network); 22 Aug 1999 23:55:14 -0000 Received: from host162.nashville.com (HELO rjlhome.sco.com) (207.65.231.162) by egcs.cygnus.com with SMTP; 22 Aug 1999 23:55:14 -0000 Received: (from robertl@localhost) by rjlhome.sco.com (8.8.8/SCO5) id SAA25423; Sun, 22 Aug 1999 18:54:17 -0500 (CDT) Date: Sun, 22 Aug 1999 18:54:17 -0500 From: Robert Lipe To: Rob Kramer Cc: egcs@egcs.cygnus.com Subject: Re: SCO 5.0.2 signal 11 + exceptions problem.. Message-ID: <19990822185417.D24619@rjlhome.sco.com> References: <37BD2C7D.1D80@singnet.com.sg> <19990820174712.A370@rjlaptop.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95us In-Reply-To: <19990820174712.A370@rjlaptop.sco.com>; from Robert Lipe on Fri, Aug 20, 1999 at 05:47:12PM -0500 Robert Lipe wrote: > Rob Kramer wrote: > > > I tried building GCC 2.95 for SCO OSR v3.2 5.0.2, and got a 'fatal > > signal > > 11 in as' somewhere along the build (while compiling 'exception.c'). > > There is a bug in the 5.0.0 and 5.0.2 assemblers that gets triggered > on 2.95 when building this file. Shortly before SCO Forum, a TLS was > submitted to the queue to provide a fixed assembler for these hosts. ftp.sco.com/TLS/ now holds tls706 which should address this situation. I should probably blast an entry into specific.html to reflect this... RJL From gcc-return-9329-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 22 23:59:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26131 invoked by alias); 22 Aug 1999 23:59:06 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26116 invoked from network); 22 Aug 1999 23:59:04 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 22 Aug 1999 23:59:04 -0000 Received: from cs.ucla.edu (ts24-14.wla.ts.ucla.edu [164.67.20.219]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id QAA29778; Sun, 22 Aug 1999 16:58:48 -0700 (PDT) Message-ID: <37C08F6F.3173F518@cs.ucla.edu> Date: Sun, 22 Aug 1999 17:01:51 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Dimitri Papadopoulos CC: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <37BEE6AA.327FE47F@cs.ucla.edu> <37BFD4C0.3B3A6261@club-internet.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, Our sysadmin was able to build 2.95.1 this time ---- apparently the problems arose because he was building 2.95.1 with 2.95 (and were solved by using egcs-1.1.2). thanks for other details -- they are very useful, Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-9330-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 00:26:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29112 invoked by alias); 23 Aug 1999 00:26:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29095 invoked from network); 23 Aug 1999 00:26:41 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 23 Aug 1999 00:26:41 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id SAA09894; Sun, 22 Aug 1999 18:25:52 -0600 X-Mailer: exmh version 2.0.2 To: Jan Hubicka cc: egcs@egcs.cygnus.com Subject: Re: New const function detection code and infinite loops. Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 22 Aug 1999 16:38:50 +0200. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Aug 1999 18:25:52 -0600 Message-ID: <9891.935367952@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > Hi > It is OK to remove call to function containing infinite loop? IMHO yes. A function with an infinite loop should never be const. jeff From gcc-return-9331-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 00:30:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30016 invoked by alias); 23 Aug 1999 00:30:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30001 invoked from network); 23 Aug 1999 00:30:12 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 23 Aug 1999 00:30:12 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id SAA09916; Sun, 22 Aug 1999 18:28:50 -0600 X-Mailer: exmh version 2.0.2 To: N8TM@aol.com cc: jsm@cygnus.com, pfeifer@dbai.tuwien.ac.at, gcc@gcc.gnu.org Subject: Re: Mailserver: DNS Check for From: Reply-To: law@cygnus.com In-reply-to: Your message of Sat, 21 Aug 1999 13:15:09 EDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Aug 1999 18:28:49 -0600 Message-ID: <9913.935368129@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > What I find more annoying is to spend some time answering a posting with no > obvious anti-spam address and then find out that replies are blocked. I'm > guessing that no measure taken by the gcc maintainers would solve this, as > the gcc site may have been specifically un-blocked by the sender. When people make it overly difficult to reply to their messages, then they deserve to lose. I do not think this kind of case is worth trying to catch. jeff From gcc-return-9332-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 00:31:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30805 invoked by alias); 23 Aug 1999 00:31:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30764 invoked from network); 23 Aug 1999 00:31:14 -0000 Received: from jpr.com (198.207.210.2) by egcs.cygnus.com with SMTP; 23 Aug 1999 00:31:14 -0000 Received: from localhost (1203 bytes) by jpr.com via sendmail with P:stdio/R:inet_hosts/T:smtp (sender: ) (ident using unix) id for ; Sun, 22 Aug 1999 20:31:08 -0400 (EDT) (Smail-3.2.0.106 1999-Mar-31 #1 built 1999-30-jun) Date: Sun, 22 Aug 1999 20:31:08 -0400 From: Jean-Pierre Radley To: EGCS Developers Subject: Re: SCO 5.0.2 signal 11 + exceptions problem.. Message-ID: <19990822203108.G25063@jpradley.jpr.com> References: <37BD2C7D.1D80@singnet.com.sg> <19990820174712.A370@rjlaptop.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3us In-Reply-To: <19990820174712.A370@rjlaptop.sco.com>; from Robert Lipe on Fri, Aug 20, 1999 at 05:47:12PM -0500 Robert Lipe opined (on Fri, Aug 20, 1999 at 05:47:12PM -0500): | | There is a bug in the 5.0.0 and 5.0.2 assemblers that gets triggered | on 2.95 when building this file. Shortly before SCO Forum, a TLS was | submitted to the queue to provide a fixed assembler for these hosts. | Since I'm on an airplane right now, I can't check ftp.sco.com/TLS to | see if it was propagated. I would be pleasantly suprised if it was; the | reality is that such things tend to take a back seat to the show. tls706 is timestamped Aug 20 09:37 (PST). -- Jean-Pierre Radley XC/XT Custodian Sysop, CompuServe SCOForum From gcc-return-9333-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 00:36:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31912 invoked by alias); 23 Aug 1999 00:36:23 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31897 invoked from network); 23 Aug 1999 00:36:22 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 23 Aug 1999 00:36:22 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id SAA09991; Sun, 22 Aug 1999 18:34:30 -0600 X-Mailer: exmh version 2.0.2 To: Mirar cc: Dimitri Papadopoulos , egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status Reply-To: law@cygnus.com In-reply-to: Your message of 21 Aug 1999 13:31:24 +0200. <826729mktv.fsf@lexx.idonex.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Aug 1999 18:34:30 -0600 Message-ID: <9988.935368470@upchuck.cygnus.com> From: Jeffrey A Law In message <826729mktv.fsf@lexx.idonex.se>you write: > As I said earlier, egcs/gcc generates illegal assembler lines for the > relocation tables. But noone seems to care, anyway... > No. The Solaris tools are buggy. jeff From gcc-return-9334-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 00:37:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 306 invoked by alias); 23 Aug 1999 00:37:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 279 invoked from network); 23 Aug 1999 00:37:49 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 23 Aug 1999 00:37:49 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id SAA10009; Sun, 22 Aug 1999 18:35:58 -0600 X-Mailer: exmh version 2.0.2 To: Dimitri Papadopoulos cc: Mirar , egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status Reply-To: law@cygnus.com In-reply-to: Your message of Sat, 21 Aug 1999 17:45:34 +0200. <37BEC99E.9BCE3572@club-internet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Aug 1999 18:35:58 -0600 Message-ID: <10006.935368558@upchuck.cygnus.com> From: Jeffrey A Law In message <37BEC99E.9BCE3572@club-internet.fr>you write: > 1) GCC does not bootstrap with Sun's fully patched C compiler 5.0. > This may be a problem with Sun's compiler, but I doubt it. > In fact 'make bootstrap' will usually fail whatever the compiler used > to bootstrap. See my messsage to this list: > GCC 2.95.1 'make bootstrap' oddities on Solaris Is this a comparison failure? If so, it is a bug in the Solaris 5.0 compilers. jeff From gcc-return-9335-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 00:54:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4471 invoked by alias); 23 Aug 1999 00:54:07 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3565 invoked from network); 23 Aug 1999 00:48:35 -0000 Received: from edison.dialix.com.au (root@203.12.2.8) by egcs.cygnus.com with SMTP; 23 Aug 1999 00:48:35 -0000 Received: from prophecy.com.au (www.prophecy.com.au [203.12.2.244]) by edison.dialix.com.au (8.9.1/8.9.1/DIALixFlat) with ESMTP id KAA28574; Mon, 23 Aug 1999 10:44:44 +1000 (EST) (envelope-from brendan@dgs.monash.edu.au) Received: from dhcp20.prophecy.com.au ([203.21.127.60] helo=dgs.monash.edu.au) by prophecy.com.au with esmtp (Exim 3.02 #1) id 11IiEz-0003Ba-00; Mon, 23 Aug 1999 10:45:37 +1000 Message-ID: <37C099D3.C0BE0BC5@dgs.monash.edu.au> Date: Mon, 23 Aug 1999 10:46:11 +1000 From: Brendan Simon Reply-To: brendan@dgs.monash.edu.au Organization: CTAM Pty Ltd X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: egcs mailing list , ecos-discuss , rtems-list , Cross-GCC Subject: GCC: different OS targets. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There seems to be different builds of egcs/gcc for various Operating Systems (eg. eCos, RTEMS). I predominantly use the powerpc-eabi target. I currently use it with No OS (NOS) on some MPC860 boards but would like to use an OS. Both RTEMS and eCos use EABI as well, so the same compiler should be useable for GCC targeting RTEMS, eCos and NOS. I would like to be able to build gcc _ONCE_ for powerpc-eabi and be able to build the RTEMS, eCos (or any other OS) libraries and install them in an appropriate place. This not only saves a lot of disk space but also a lot time recompiling for each OS evertime a new version of GCC is released (or snapshots). I figure that the -m switch might be appropriate for choosing the operating system. Powerpc has a -mads (amongst others) switch which links the ads crt0.o file and libads via the specs file. Does the specs file only work with the -m switch all will it work with any other swtich ? The -m switch could be used to select the operating system. eg. "-m ads-rtems" or "-m rtems-ads". A separate directory for the OS stuff would be setup in $prefix$target/$os (eg. /usr/local/gcc/rtems/include and /usr/local/gcc/rtems/lib) or maybe $prefix/$target/os/$os (eg. /usr/local/gcc/os/rtems/... or /usr/local/gcc/os/none/...). I know this would take some cooperation between the OS vendors that support GCC but I believe that it would be worth it. Please voice your opinion if you think this is a good or bad idea. Brendan Simon. PS. I have used eCos and RTEMS as examples only. I'm sure there are other OSs that use gcc (vxworks) that would benefit from a formal mehod of implemting multiple OSs using the one compiler. From gcc-return-9336-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 01:21:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8126 invoked by alias); 23 Aug 1999 01:21:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8101 invoked from network); 23 Aug 1999 01:21:25 -0000 Received: from piglet.dstc.edu.au (130.102.176.1) by egcs.cygnus.com with SMTP; 23 Aug 1999 01:21:25 -0000 Received: from azure.dstc.edu.au (azure.dstc.edu.au [130.102.176.27]) by piglet.dstc.edu.au (8.9.3/8.9.3) with ESMTP id LAA12207 for ; Mon, 23 Aug 1999 11:21:20 +1000 (EST) Date: Mon, 23 Aug 1999 11:21:20 +1000 (EST) From: jason andrade To: gcc@gcc.gnu.org Subject: direct mirror for australia Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII hi, we are now directly mirroring gcc from sourceware.egcs.com daily here at aarnet's mirror site in australia ftp://mirror.aarnet.edu.au/pub/egcs/ regards, -jason jason andrade dstc pty ltd jason@dstc.edu.au senior sysadmin level 7, GPS Building 78 i just wanna be phn +61-7-33654307 university of queensland bluemisty fax +61-7-33654311 queensland 4072 australia and barefooted From gcc-return-9337-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 01:52:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10299 invoked by alias); 23 Aug 1999 01:52:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10284 invoked from network); 23 Aug 1999 01:52:31 -0000 Received: from web122.yahoomail.com (205.180.60.57) by egcs.cygnus.com with SMTP; 23 Aug 1999 01:52:31 -0000 Message-ID: <19990823015313.17370.rocketmail@web122.yahoomail.com> Received: from [131.111.99.243] by web122.yahoomail.com; Sun, 22 Aug 1999 18:53:13 PDT Date: Sun, 22 Aug 1999 18:53:13 -0700 (PDT) From: sysadm Subject: BUILDING JAVA 2.95 LIB To: gcc@gcc.gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I was trying the weekend to build the JAVA lib 2.95. The gzip-untar creates a dir with configure, dir libjava, dir zip, dir zlib, etc... Any attempt to give ./configure fails , the configure exits immediatelly. cd to libjava then ./configure again fails. Why??? Do I need I source tree of gcc-2.95 somewhere and a decalration of it (to the libjava configure script)? Certainly ./configure --help doesnt list that... Please advise. Best Regards, Alex __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From gcc-return-9338-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 02:15:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12114 invoked by alias); 23 Aug 1999 02:15:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12095 invoked from network); 23 Aug 1999 02:15:53 -0000 Received: from ss1000.ms.mff.cuni.cz (root@195.113.19.221) by egcs.cygnus.com with SMTP; 23 Aug 1999 02:15:53 -0000 Received: from u-sl0.ms.mff.cuni.cz (IDENT:jhub6202@u-sl0.ms.mff.cuni.cz [195.113.16.50]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id EAA27141; Mon, 23 Aug 1999 04:15:50 +0200 Received: from localhost (jhub6202@localhost) by u-sl0.ms.mff.cuni.cz (8.8.8/8.8.8) with SMTP id EAA19334; Mon, 23 Aug 1999 04:15:49 +0200 X-Authentication-Warning: u-sl0.ms.mff.cuni.cz: jhub6202 owned process doing -bs Date: Mon, 23 Aug 1999 04:15:49 +0200 (MET DST) From: Jan Hubicka X-Sender: jhub6202@u-sl0.ms.mff.cuni.cz To: Jeffrey A Law cc: egcs@egcs.cygnus.com Subject: Re: New const function detection code and infinite loops. In-Reply-To: <9891.935367952@upchuck.cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 22 Aug 1999, Jeffrey A Law wrote: > In message you > write: > > Hi > > It is OK to remove call to function containing infinite loop? > IMHO yes. A function with an infinite loop should never be const. Thats true. But our new const detection code will happily mark such function to be const. Thats wrong (because that function will be removed) Honza > > > jeff > From gcc-return-9339-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 02:32:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13612 invoked by alias); 23 Aug 1999 02:32:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13597 invoked from network); 23 Aug 1999 02:32:50 -0000 Received: from postal.thewrittenword.com (china@208.150.51.101) by egcs.cygnus.com with SMTP; 23 Aug 1999 02:32:50 -0000 Received: (from china@localhost) by postal.thewrittenword.com (8.9.3/8.9.3) id VAA21230; Sun, 22 Aug 1999 21:28:13 -0500 (CDT) Date: Sun, 22 Aug 1999 21:28:12 -0500 From: egcs@thewrittenword.com To: Igor Markov Cc: Dimitri Papadopoulos , egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status Message-ID: <19990822212812.A16796@postal.thewrittenword.com> Reply-To: egcs@egcs.cygnus.com References: <37BEE6AA.327FE47F@cs.ucla.edu> <37BFD4C0.3B3A6261@club-internet.fr> <37C08F6F.3173F518@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <37C08F6F.3173F518@cs.ucla.edu>; from Igor Markov on Sun, Aug 22, 1999 at 05:01:51PM -0700 On Sun, Aug 22, 1999 at 05:01:51PM -0700, Igor Markov wrote: > Our sysadmin was able to build 2.95.1 this time ---- > apparently the problems arose because he was building 2.95.1 with 2.95 > (and were solved by using egcs-1.1.2). > > thanks for other details -- they are very useful, We built 2.95.1 on Solaris 2.5.1, 2.6, 2.7/SPARC with Sun as/ld and gcc 2.95 without any problems. However, trying to build 2.95.1 on these platforms with the Sun v5.0 compiler fails: Comparing stage2 and stage3 of the compiler ... rm -f tmp-foo* case "compare" in compare | compare-lean ) stage=2 ;; * ) stage=`echo compare | sed -e 's,^compare\([0-9][0-9]*\).*,\1,'` ;; esac; \ if [ -f .bad_compare ]; then \ echo "Bootstrap comparison failure!"; \ cat .bad_compare; \ exit 1; \ else \ case "compare" in \ *-lean ) rm -rf stage$stage ;; \ *) ;; \ esac; true; \ fi Bootstrap comparison failure! emit-rtl.o differs gmake[1]: *** [compare] Error 1 gmake[1]: Leaving directory `/opt/build/gcc-2.95.1/objdir/gcc' gmake: *** [bootstrap] Error 2 Building failed. Exiting. We also cannot build 2.95.1 on HP-UX 10.20 with the HP C compiler (the one you buy, not the one that comes with the OS). > Igor Markov office: (310) 206-0179 -- albert chin (china@thewrittenword.com) From gcc-return-9340-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 02:36:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14501 invoked by alias); 23 Aug 1999 02:36:02 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14480 invoked from network); 23 Aug 1999 02:35:47 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 23 Aug 1999 02:35:47 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id WAA00275; Sun, 22 Aug 1999 22:35:41 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id WAA21753; Sun, 22 Aug 1999 22:35:40 -0400 (EDT) Date: Sun, 22 Aug 1999 22:35:40 -0400 (EDT) From: John Wehle Message-Id: <199908230235.WAA21753@jwlab.FEITH.COM> To: jhub6202@ss1000.ms.mff.cuni.cz cc: egcs@egcs.cygnus.com, law@cygnus.com Subject: Re: New const function detection code and infinite loops. Content-Type: text > On Sun, 22 Aug 1999, Jeffrey A Law wrote: > > In message you >> write: >> > Hi >> > It is OK to remove call to function containing infinite loop? >> IMHO yes. A function with an infinite loop should never be const. > Thats true. But our new const detection code will happily mark such > function to be const. Thats wrong (because that function will be removed) Does this function containing an infinite loop return a value? If it is void, then the new const detection code will not mark the function as const. Likewise if the function is marked volatile. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-9341-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 04:11:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22649 invoked by alias); 23 Aug 1999 04:11:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22604 invoked from network); 23 Aug 1999 04:11:24 -0000 Received: from ss1000.ms.mff.cuni.cz (root@195.113.19.221) by egcs.cygnus.com with SMTP; 23 Aug 1999 04:11:24 -0000 Received: from u-sl0.ms.mff.cuni.cz (IDENT:jhub6202@u-sl0.ms.mff.cuni.cz [195.113.16.50]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id GAA32216; Mon, 23 Aug 1999 06:11:15 +0200 Received: from localhost (jhub6202@localhost) by u-sl0.ms.mff.cuni.cz (8.8.8/8.8.8) with SMTP id GAA22546; Mon, 23 Aug 1999 06:11:14 +0200 X-Authentication-Warning: u-sl0.ms.mff.cuni.cz: jhub6202 owned process doing -bs Date: Mon, 23 Aug 1999 06:11:14 +0200 (MET DST) From: Jan Hubicka X-Sender: jhub6202@u-sl0.ms.mff.cuni.cz To: John Wehle cc: egcs@egcs.cygnus.com, law@cygnus.com Subject: Re: New const function detection code and infinite loops. In-Reply-To: <199908230235.WAA21753@jwlab.FEITH.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > Does this function containing an infinite loop return a value? If it > is void, then the new const detection code will not mark the function Well and for example following function: int funct(int b) { while(b&1) b+=2; return b; } main() { funct(1); } despite the fact, that function is complette nonsence, it still contains infinite loop (for certain input values), but will be marked as const by the detection code. So this program will terminate. Maybe this is ANSI-C conforming, but I don't believe so. > as const. Likewise if the function is marked volatile. I think that functions may not be volatile and volatile flag means "noreturn" attribute. Or am I wrong? I've already implemented detection code for "noreturn" attribute and function marking to volatile seemd to do the trick. In fact I started to worry about the infinite loops when one function got both attributes detected. Also detecting of void functions as const IMO still makes sense (internally only, not as attribute), because calls to the may be completely ignored. Such functions happends sometimes when they are present as placeholders. This happends even in GCC tree. Honza > > -- John > ------------------------------------------------------------------------- > | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | > | John Wehle | Fax: 1-215-540-5495 | | > ------------------------------------------------------------------------- > From gcc-return-9342-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 04:22:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24192 invoked by alias); 23 Aug 1999 04:22:29 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24150 invoked from network); 23 Aug 1999 04:22:27 -0000 Received: from ppp0b017.std.com (HELO grouper.coelacanth.com) (208.192.101.17) by egcs.cygnus.com with SMTP; 23 Aug 1999 04:22:27 -0000 Received: (from roger@localhost) by grouper.coelacanth.com (8.8.7/8.8.7) id XAA02900; Sun, 22 Aug 1999 23:33:37 -0400 To: egcs mailing list , ecos-discuss , Cross-GCC Subject: Re: GCC: different OS targets. References: <37C099D3.C0BE0BC5@dgs.monash.edu.au> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Roger Williams Date: 22 Aug 1999 23:33:37 -0400 In-Reply-To: Brendan Simon's message of "Mon, 23 Aug 1999 10:46:11 +1000" Message-ID: Organization: Coelacanth Engineering Inc Lines: 17 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" >>>>> Brendan Simon writes: > I would like to be able to build gcc _ONCE_ for powerpc-eabi and > be able to build the RTEMS, eCos (or any other OS) libraries and > install them in an appropriate place. Yes indeed, this would be *very* helpful. I'm currently developing MPC8xx code for no-OS, Linux, and Neutrino, and I have separate development installations for each of these. I want to start working with eCos, but I dread the thought of yet another set of powerpc-eabi tools and libraries... -- Roger Williams finger me for my PGP public key Coelacanth Engineering Inc consulting & turnkey product development Middleborough, Massachusetts wireless * datacomm * DSP * ATE tel +1 508 947-5585 * fax +1 508 861-0278 * http://www.coelacanth.com/ From gcc-return-9343-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 05:04:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27606 invoked by alias); 23 Aug 1999 05:04:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27591 invoked from network); 23 Aug 1999 05:04:07 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 23 Aug 1999 05:04:07 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id BAA02092; Mon, 23 Aug 1999 01:04:03 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id BAA22043; Mon, 23 Aug 1999 01:04:01 -0400 (EDT) Date: Mon, 23 Aug 1999 01:04:01 -0400 (EDT) From: John Wehle Message-Id: <199908230504.BAA22043@jwlab.FEITH.COM> To: jhub6202@ss1000.ms.mff.cuni.cz cc: egcs@egcs.cygnus.com, law@cygnus.com Subject: Re: New const function detection code and infinite loops. Content-Type: text > int funct(int b) > { > while(b&1) b+=2; > return b; > } > main() > { > funct(1); > } > despite the fact, that function is complette nonsence, it still contains > infinite loop (for certain input values), but will be marked as const by > the detection code. So this program will terminate. Maybe this is ANSI-C > conforming, but I don't believe so. I'm not following you. Are you saying that the program may be ANSI-C conforming, or the new behavior of the compiler? I believe that marking the function as const allows CSE to remove * redundant * calls which means that the infinite loop will still occur for certain inputs, just not as many infinite loops as would otherwise happen. I'm not sure in what situation having fewer infinite loops for a given input creates a problem unless you are thinking of situations where an external event is causing control to leave the loop in which cause the loop may be quite deliberate and perhaps should be marked volatile. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-9344-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 06:56:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1815 invoked by alias); 23 Aug 1999 06:56:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1798 invoked from network); 23 Aug 1999 06:56:45 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 23 Aug 1999 06:56:45 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.9.3/8.9.3) with ESMTP id AAA25012; Mon, 23 Aug 1999 00:02:03 -0700 To: jhub6202@ss1000.ms.mff.cuni.cz Cc: john@feith.com, egcs@egcs.cygnus.com, law@cygnus.com Subject: Re: New const function detection code and infinite loops. In-Reply-To: References: <199908230235.WAA21753@jwlab.FEITH.COM> X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990823000203L.mitchell@codesourcery.com> Date: Mon, 23 Aug 1999 00:02:03 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 55 Well and for example following function: int funct(int b) { while(b&1) b+=2; return b; } main() { funct(1); } despite the fact, that function is complette nonsence, it still contains infinite loop (for certain input values), but will be marked as const by the detection code. If I follow, you're saying that some part of the compiler works like this: 1. A `const' function is one that doesn't read or write any global memory. This is automatically detected, and `funct' is marked as `const'. 2. Therefore, a `const' function has no side-effects. 3. Therefore, if the value of a `const' function is not used, the call to the `const' function can be omitted. The GCC documentation for the `const' attribute says: Many functions do not examine any values except their arguments, and have no effects except the return value. As you note, running forever *is* an effect. Therefore, `funct' is not `const'. Therefore, the const-detection code should not detect this case. It could be conservative by not including any function with a loop (including a goto), or a function call. (Because a function call could indicate recursion. I guess you could technically ignore function calls; if that's the way by which you get infinite looping then you'll get a stack overflow, which is undefined behavior, which means that you can do anything you want. But, I think it would be better to treat function calls like potential loops.) Some other attribute (I think this is the `pure' attribute) *does* apply to such functions. It says that this function may have loop forever, but is guaranteed to return the same value whenever it is called with the same arguments, and does not affect global memory. So, you can turn `funct (1) + funct (1)' into `2 * funct(1)', or even `funct (1)', if you're not using the value. (BTW, technically, your program has undefined behavior because `b' will overflow. If you made `b' an unsigned int, the behavior would be defined.) -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-9345-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 07:08:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5527 invoked by alias); 23 Aug 1999 07:08:31 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5494 invoked from network); 23 Aug 1999 07:08:29 -0000 Received: from nenuphar.saclay.cea.fr (132.166.192.7) by egcs.cygnus.com with SMTP; 23 Aug 1999 07:08:29 -0000 Received: from muguet.saclay.cea.fr (muguet.saclay.cea.fr [132.166.192.6]) by nenuphar.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.0.D20) with ESMTP id JAA04658 for ; Mon, 23 Aug 1999 09:08:24 +0200 (MET DST) Received: from pendragon-int.shfj.cea.fr (pendragon.shfj.cea.fr [132.166.81.1]) by muguet.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.1.D20) with SMTP id JAA02313 for ; Mon, 23 Aug 1999 09:08:24 +0200 (MET DST) Received: by pendragon-int.shfj.cea.fr; id JAA05801; Mon, 23 Aug 1999 09:02:15 +0200 Received: from uriens.shfj.cea.fr(193.48.23.6) by pendragon-int.shfj.cea.fr via smap (3.2) id xma005754; Mon, 23 Aug 99 09:02:08 +0200 Received: from orcanie.shfj.cea.fr by shfj.cea.fr (8.6.10/PROTO-CEANET-3.0) with ESMTP id JAA12970 for ; Mon, 23 Aug 1999 09:07:34 +0200 Received: from orcanie (orcanie [193.48.23.116]) by orcanie.shfj.cea.fr (8.9.1b+Sun/8.9.1) with SMTP id JAA09852 for ; Mon, 23 Aug 1999 09:08:32 +0200 (MET DST) Message-Id: <199908230708.JAA09852@orcanie.shfj.cea.fr> Date: Mon, 23 Aug 1999 09:08:32 +0200 (MET DST) From: Dimitri PAPADOPOULOS-ORFANOS Reply-To: Dimitri PAPADOPOULOS-ORFANOS Subject: Re: egcs/Solaris status To: egcs@egcs.cygnus.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7EZ1spJxtT20WW3ntb+fSQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc > In message <826729mktv.fsf@lexx.idonex.se>you write: > > As I said earlier, egcs/gcc generates illegal assembler lines for the > > relocation tables. But noone seems to care, anyway... > > No. The Solaris tools are buggy. OK. Solaris tools may be buggy, but GCC is supposed to work on Solaris. Sun compilers don't have problems with Sun as/ld so there must be some way to make GCC function properly on Solaris, even with buggy Solaris tools. Is a clear description of the incompatibilities between GCC and and Sun as/ld to be found somewehere? If so, we could: - Massively complain to Sun so that the bug gets fixed. I will complain if I can understand what the problem is. Of course, Sun are much like Microsoft, they don't care about customers. Last time I complained about as not reading lines more than 1024 characters long, they told me to use their broken C++ compiler. But it appears that this bug eventually got fixed. - Adapt GCC to work properly on Solaris until the bugs get fixed, so that shared objects built with cc and the GCC C compiler can be used together... From gcc-return-9346-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 07:20:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7338 invoked by alias); 23 Aug 1999 07:20: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7312 invoked from network); 23 Aug 1999 07:20:17 -0000 Received: from nenuphar.saclay.cea.fr (132.166.192.7) by egcs.cygnus.com with SMTP; 23 Aug 1999 07:20:17 -0000 Received: from muguet.saclay.cea.fr (muguet.saclay.cea.fr [132.166.192.6]) by nenuphar.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.0.D20) with ESMTP id JAA06842 for ; Mon, 23 Aug 1999 09:20:15 +0200 (MET DST) Received: from pendragon-int.shfj.cea.fr (pendragon.shfj.cea.fr [132.166.81.1]) by muguet.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.1.D20) with SMTP id JAA04279 for ; Mon, 23 Aug 1999 09:18:55 +0200 (MET DST) Received: by pendragon-int.shfj.cea.fr; id JAA06873; Mon, 23 Aug 1999 09:12:46 +0200 Received: from uriens.shfj.cea.fr(193.48.23.6) by pendragon-int.shfj.cea.fr via smap (3.2) id xma006836; Mon, 23 Aug 99 09:12:33 +0200 Received: from orcanie.shfj.cea.fr by shfj.cea.fr (8.6.10/PROTO-CEANET-3.0) with ESMTP id JAA13088 for ; Mon, 23 Aug 1999 09:18:00 +0200 Received: from orcanie (orcanie [193.48.23.116]) by orcanie.shfj.cea.fr (8.9.1b+Sun/8.9.1) with SMTP id JAA10252 for ; Mon, 23 Aug 1999 09:18:58 +0200 (MET DST) Message-Id: <199908230718.JAA10252@orcanie.shfj.cea.fr> Date: Mon, 23 Aug 1999 09:18:58 +0200 (MET DST) From: Dimitri PAPADOPOULOS-ORFANOS Reply-To: Dimitri PAPADOPOULOS-ORFANOS Subject: Re: egcs/Solaris status To: egcs@egcs.cygnus.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cUN2VBU/vffU3Ai94uvh3g== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc > In message <37BEC99E.9BCE3572@club-internet.fr>you write: > > 1) GCC does not bootstrap with Sun's fully patched C compiler 5.0. > > This may be a problem with Sun's compiler, but I doubt it. > > In fact 'make bootstrap' will usually fail whatever the compiler used > > to bootstrap. See my messsage to this list: > > GCC 2.95.1 'make bootstrap' oddities on Solaris > Is this a comparison failure? If so, it is a bug in the Solaris 5.0 compilers. No. One of the utilities segfaults, just like when I try to 'make bootstrap' GCC with EGCS 1.1.2 in the following configuration: - GNU as/ld are not in the PATH. - However EGCS is using GNU as/ld internally, using the technique described in the FAQ. I don't remember which program did segfault. Something like 'gen...' I think. If this is of interest, I can try once again, with and without GNU as/ld in the PATH. From gcc-return-9347-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 07:35:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12395 invoked by alias); 23 Aug 1999 07:35:14 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12314 invoked from network); 23 Aug 1999 07:35:04 -0000 Received: from edison.dialix.com.au (root@203.12.2.8) by egcs.cygnus.com with SMTP; 23 Aug 1999 07:35:04 -0000 Received: from prophecy.com.au (www.prophecy.com.au [203.12.2.244]) by edison.dialix.com.au (8.9.1/8.9.1/DIALixFlat) with ESMTP id RAA12095; Mon, 23 Aug 1999 17:34:53 +1000 (EST) (envelope-from brendan@dgs.monash.edu.au) Received: from dhcp20.prophecy.com.au ([203.21.127.60] helo=dgs.monash.edu.au) by prophecy.com.au with esmtp (Exim 3.02 #1) id 11Ioe1-0007BI-00; Mon, 23 Aug 1999 17:35:53 +1000 Message-ID: <37C0F9F5.FC29C7D3@dgs.monash.edu.au> Date: Mon, 23 Aug 1999 17:36:21 +1000 From: Brendan Simon Reply-To: brendan@dgs.monash.edu.au Organization: CTAM Pty Ltd X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 CC: egcs mailing list , Cross-GCC Subject: Re: GCC: different OS targets. References: <37C099D3.C0BE0BC5@dgs.monash.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roger Williams wrote: > >>>>> Brendan Simon writes: > > > I would like to be able to build gcc _ONCE_ for powerpc-eabi and > > be able to build the RTEMS, eCos (or any other OS) libraries and > > install them in an appropriate place. > > Yes indeed, this would be *very* helpful. I'm currently developing > MPC8xx code for no-OS, Linux, and Neutrino, and I have separate > development installations for each of these. I want to start working > with eCos, but I dread the thought of yet another set of powerpc-eabi > tools and libraries... I've had a look through the gcc info files and noticed LOTS of -m command line switches (eg. -mcall-linux, -mcall-sysv, -mcall-sysv-eabi, -mcall-sysv, -mcall-aix, -mcall-solaris, ...). Does this mean that I can have _ONE_ gcc compiler for all my needs ? If so, why is it common practise to build gcc with targets such as "powerpc-eabi", "powerpc-aix", "powerpc-linux", etc ? Sure all one needs is something like "powerpc". If the others are used to set the default output style then surely this could be set with a configure command such as --enable-call-aix or --default-call-aix or --with-call-aix (you get the picture). Brendan Simon. From gcc-return-9348-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 08:41:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22041 invoked by alias); 23 Aug 1999 08:41:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21991 invoked from network); 23 Aug 1999 08:41:41 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 23 Aug 1999 08:41:41 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id KAA16418; Mon, 23 Aug 1999 10:40:40 +0200 (MET DST) Date: Mon, 23 Aug 1999 10:40:40 +0200 (MET DST) From: Gerald Pfeifer To: Robert Lipe cc: Rob Kramer , egcs@egcs.cygnus.com Subject: Re: SCO 5.0.2 signal 11 + exceptions problem.. In-Reply-To: <19990822185417.D24619@rjlhome.sco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 22 Aug 1999, Robert Lipe wrote: > I should probably blast an entry into specific.html to reflect this... Yeah, please. A note to all port maintainers: Please update entries of your ports in install/specific.html as you see fit; just submit the patch to gcc-patches after the fact. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9349-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 10:12:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5348 invoked by alias); 23 Aug 1999 10:12:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5326 invoked from network); 23 Aug 1999 10:12:00 -0000 Received: from nenuphar.saclay.cea.fr (132.166.192.7) by egcs.cygnus.com with SMTP; 23 Aug 1999 10:12:00 -0000 Received: from muguet.saclay.cea.fr (muguet.saclay.cea.fr [132.166.192.6]) by nenuphar.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.0.D20) with ESMTP id MAA14059 for ; Mon, 23 Aug 1999 12:11:59 +0200 (MET DST) Received: from pendragon-int.shfj.cea.fr (pendragon.shfj.cea.fr [132.166.81.1]) by muguet.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.1.D20) with SMTP id MAA11501; Mon, 23 Aug 1999 12:11:58 +0200 (MET DST) Received: by pendragon-int.shfj.cea.fr; id MAA16529; Mon, 23 Aug 1999 12:05:49 +0200 Received: from uriens.shfj.cea.fr(193.48.23.6) by pendragon-int.shfj.cea.fr via smap (3.2) id xma016517; Mon, 23 Aug 99 12:05:42 +0200 Received: from orcanie.shfj.cea.fr by shfj.cea.fr (8.6.10/PROTO-CEANET-3.0) with ESMTP id MAA14783 ; Mon, 23 Aug 1999 12:11:08 +0200 Received: from orcanie (orcanie [193.48.23.116]) by orcanie.shfj.cea.fr (8.9.1b+Sun/8.9.1) with SMTP id KAA13860; Mon, 23 Aug 1999 10:58:54 +0200 (MET DST) Message-Id: <199908230858.KAA13860@orcanie.shfj.cea.fr> Date: Mon, 23 Aug 1999 10:58:54 +0200 (MET DST) From: Dimitri PAPADOPOULOS-ORFANOS Reply-To: Dimitri PAPADOPOULOS-ORFANOS Subject: Re: egcs/Solaris status To: Alexandre Oliva Cc: egcs@egcs.cygnus.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: sImcN6+gRHGaD165VUp18w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Alexandre Oliva wrote: > On Aug 21, 1999, Dimitri Papadopoulos wrote: > > > 3) I get segfault/aritmetic exception in Qt (http://www.troll.no/),even > > without -O. The problem is not with Qt: > > - The very same source compiled with egcs-1.1.2 or Sun CC does not > > crash. > > Did you try to compile with -fno-strict-aliasing? -fstring-aliasing, > now enabled by default, has caused some problems to packages that use > certain kinds of casts of pointers with undefined results. I tried to compile with -fno-strict-aliasing and using GNU as/ld this morning. I still get the same segfault. I believe the assembler generated by GCC contains errors. While this was true of EGCS for optimisation levels higher than -O2, with GCC this now seems to happen even without optimisation. I will investigate further... The problem is that 'this' is an invalid pointer in method 'QGDict::look_ascii': it has never been allocated. I added code to the QGDict constructor to monitor the addresses of GGDict objects: 'this' is not in the set of existing 'QGDict' addresses. I will try to find where and how this invalid address is generated. By the way, the problem arises only when using dynamic libraries. I don't have any problems when using the static Qt library. Does this mean anything? -- Dimitri Papadopoulos From gcc-return-9350-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 11:46:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13796 invoked by alias); 23 Aug 1999 11:46:01 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13773 invoked from network); 23 Aug 1999 11:45:55 -0000 Received: from rainer.informatik.uni-stuttgart.de (root@129.69.183.1) by egcs.cygnus.com with SMTP; 23 Aug 1999 11:45:55 -0000 Received: from rainer.informatik.uni-stuttgart.de ([127.0.0.1]) by rainer.informatik.uni-stuttgart.de with esmtp (ident rainer using rfc1413) id m11IsXp-000HVzC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Mon, 23 Aug 1999 13:45:45 +0200 (CEST) Message-Id: X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: gcc@gcc.gnu.org Subject: Building binutils on Solaris Reply-To: rainer.dorsch@informatik.uni-stuttgart.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Aug 1999 13:45:44 +0300 From: Rainer Dorsch The install/BUILD document says: Building a native compiler For a native build issue the command `make bootstrap'. This will build the entire GCC system, which includes the following steps: [...] * Build target tools for use by the compiler such as gas, gld, and binutils if they have been properly unpacked into the GCC source tree. What does properly unpacked mean? I unpacked binutils on Solaris in gcc-2.95.1/binutils-2.9 (and made a link from binutils to binutils-2.9) but no gas is build when I do make bootstrap in the objdir. Even if I configure binutils before! Thanks for any suggestion. -- Rainer Dorsch Abt. Rechnerarchitektur e-mail:rainer.dorsch@informatik.uni-stuttgart.de Uni Stuttgart Tel.: 0711-7816-215 From gcc-return-9351-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 13:10:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11393 invoked by alias); 23 Aug 1999 13:10:21 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11377 invoked from network); 23 Aug 1999 13:10:14 -0000 Received: from nenuphar.saclay.cea.fr (132.166.192.7) by egcs.cygnus.com with SMTP; 23 Aug 1999 13:10:14 -0000 Received: from muguet.saclay.cea.fr (muguet.saclay.cea.fr [132.166.192.6]) by nenuphar.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.0.D20) with ESMTP id PAA14464 for ; Mon, 23 Aug 1999 15:10:06 +0200 (MET DST) Received: from pendragon-int.shfj.cea.fr (pendragon.shfj.cea.fr [132.166.81.1]) by muguet.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.1.D20) with SMTP id PAA12103; Mon, 23 Aug 1999 15:10:05 +0200 (MET DST) Received: by pendragon-int.shfj.cea.fr; id PAA19159; Mon, 23 Aug 1999 15:03:57 +0200 Received: from uriens.shfj.cea.fr(193.48.23.6) by pendragon-int.shfj.cea.fr via smap (3.2) id xma019155; Mon, 23 Aug 99 15:03:51 +0200 Received: from orcanie.shfj.cea.fr by shfj.cea.fr (8.6.10/PROTO-CEANET-3.0) with ESMTP id PAA18807 ; Mon, 23 Aug 1999 15:09:15 +0200 Received: from orcanie (orcanie [193.48.23.116]) by orcanie.shfj.cea.fr (8.9.1b+Sun/8.9.1) with SMTP id PAA06803; Mon, 23 Aug 1999 15:10:15 +0200 (MET DST) Message-Id: <199908231310.PAA06803@orcanie.shfj.cea.fr> Date: Mon, 23 Aug 1999 15:10:15 +0200 (MET DST) From: Dimitri PAPADOPOULOS-ORFANOS Reply-To: Dimitri PAPADOPOULOS-ORFANOS Subject: Re: egcs/Solaris status To: law@cygnus.com Cc: egcs@egcs.cygnus.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: h91Wq/XR3cpkvxYhL33gtw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Jerffery A Law wrote: > In message <37BEC99E.9BCE3572@club-internet.fr>you write: > > 1) GCC does not bootstrap with Sun's fully patched C compiler 5.0. > > This may be a problem with Sun's compiler, but I doubt it. > > In fact 'make bootstrap' will usually fail whatever the compiler used > > to bootstrap. See my messsage to this list: > > GCC 2.95.1 'make bootstrap' oddities on Solaris > Is this a comparison failure? If so, it is a bug in the Solaris 5.0 compilers. No, this is not a comparison failure, but it could well be a bug in the Solaris 5.0 compiler. I tried to build GCC with a fully patched Sun C compiler once again. Here are the results: $ uname -a SunOS orcanie 5.7 Generic sun4u sparc SUNW,Ultra-30 $ where as ld cc /usr/ccs/bin/as /usr/ccs/bin/ld /opt/SUNWspro/bin/cc $ where gcc gcc: Command not found. $ ./configure --enable-shared --enable-threads Configuring for a sparc-sun-solaris2.7 host. [...] checking for gcc... cc checking whether we are using GNU C... no [...] $ make bootstrap [...] stage1/xgcc -Bstage1/ -B/pub_dom/gcc-2.95.1/sparc-sun-solaris2.7/bin/ -DIN_GCC -DHAIFA -DSVR4 -O2 -g -DHAVE_CONFIG_H -o genpeep \ genpeep.o rtl.o bitmap.o print-rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ` case "" in ?*) echo ;; esac ` ./genpeep ./config/sparc/sparc.md > tmp-peep.c Segmentation Fault make[2]: *** [s-peep] Error 139 make[2]: Leaving directory `/home/papadopo/gcc-2.95.1/gcc' make[1]: *** [bootstrap] Error 2 make[1]: Leaving directory `/home/papadopo/gcc-2.95.1/gcc' make: *** [bootstrap] Error 2 $ Then I tried this: $ cd gcc $ gdb ./genpeep GNU gdb 4.17 [...] This GDB was configured as "sparc-sun-solaris2.5.1"... Breakpoint 1 at 0x2780c Breakpoint 2 at 0x11404: file ./genpeep.c, line 440. Breakpoint 3 at 0x27854 (gdb) set args ./config/sparc/sparc.md (gdb) run Starting program: /home/papadopo/gcc-2.95.1/gcc/./genpeep ./config/sparc/sparc.md Breakpoint 1 at 0xff31680c Breakpoint 3 at 0xff2b91e0 Program received signal SIGSEGV, Segmentation fault. 0xff2b6c5c in strlen () (gdb) where #0 0xff2b6c5c in strlen () #1 0x12bf8 in init_rtl () at rtl.c:910 #2 0x11490 in main (argc=2, argv=0x26c00) at ./genpeep.c:466 (gdb) The problem is in init_rtl () at rtl.c:910 where rtx_length[i] = strlen (rtx_format[i]); but i is 126 and 'rtx_format[i]' is 0x0. I can't see no reason for 'rtx_format[i]' being 0x0: file 'rtl.def' contains 127 occurences of DEF_RTL_EXPR and thus defines 'rtx_code[i]' for values from 0 to 126 included. Also, I checked in object files that the value of enum LAST_AND_UNUSED_RTX_CODE is 127. Then 'rtx-format' array is initialised with char *rtx_format[] = { #define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS) FORMAT , #include "rtl.def" /* rtl expressions are defined here */ #undef DEF_RTL_EXPR }; A bug in the Sun C compiler? I can't reproduce in a small piece code. If anyone has ideas, I am willing to perform further checks on our Solaris machine. -- Dimitri Papadopoulos From gcc-return-9352-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 14:17:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19274 invoked by alias); 23 Aug 1999 14:17:39 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19258 invoked from network); 23 Aug 1999 14:17:35 -0000 Received: from pop01.mail.com (HELO pop01.pub02) (165.251.48.110) by egcs.cygnus.com with SMTP; 23 Aug 1999 14:17:35 -0000 Received: from mail.com (56k93-118.cyberport.com [204.134.118.93]) by pop01.pub02 (8.9.1/8.9.1) with ESMTP id KAA15573 for ; Mon, 23 Aug 1999 10:17:33 -0400 (EDT) Message-ID: <37C157C7.59E39942@mail.com> Date: Mon, 23 Aug 1999 08:16:39 -0600 From: Warren Young Organization: -ENOENT X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: egcs Mailing List Subject: Re: pgcc status? References: <746.899T1266T10104626@kampsax.k-net.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rask Ingemann Lambertsen wrote: > > The latter one does look dead: > > The following error was encountered: > Unable to determine IP address from host name for www.gcc.ml.org Yeah, *.ml.org died many many months ago. It may even be a year now. No doubt some other dynamic DNS service hosts that site now, but .ml.org certainly isn't it. -- = Warren = ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m From gcc-return-9353-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 14:49:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24276 invoked by alias); 23 Aug 1999 14:49:16 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24206 invoked from network); 23 Aug 1999 14:49:09 -0000 Received: from ss1000.ms.mff.cuni.cz (root@195.113.19.221) by egcs.cygnus.com with SMTP; 23 Aug 1999 14:49:09 -0000 Received: from u-sl0.ms.mff.cuni.cz (IDENT:jhub6202@u-sl0.ms.mff.cuni.cz [195.113.16.50]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id QAA17287; Mon, 23 Aug 1999 16:48:59 +0200 Received: from localhost (jhub6202@localhost) by u-sl0.ms.mff.cuni.cz (8.8.8/8.8.8) with SMTP id QAA08482; Mon, 23 Aug 1999 16:48:59 +0200 X-Authentication-Warning: u-sl0.ms.mff.cuni.cz: jhub6202 owned process doing -bs Date: Mon, 23 Aug 1999 16:48:58 +0200 (MET DST) From: Jan Hubicka X-Sender: jhub6202@u-sl0.ms.mff.cuni.cz To: Mark Mitchell cc: john@feith.com, egcs@egcs.cygnus.com, law@cygnus.com Subject: Re: New const function detection code and infinite loops. In-Reply-To: <19990823000203L.mitchell@codesourcery.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 23 Aug 1999, Mark Mitchell wrote: > > Well and for example following function: > > int funct(int b) > { > while(b&1) b+=2; > return b; > } > main() > { > funct(1); > } > despite the fact, that function is complette nonsence, it still contains > infinite loop (for certain input values), but will be marked as const by > the detection code. > > If I follow, you're saying that some part of the compiler works like > this: > > 1. A `const' function is one that doesn't read or write any global > memory. This is automatically detected, and `funct' is marked > as `const'. > 2. Therefore, a `const' function has no side-effects. > 3. Therefore, if the value of a `const' function is not used, the > call to the `const' function can be omitted. Thats exactly what I do have in mind. > > The GCC documentation for the `const' attribute says: > > Many functions do not examine any values except their arguments, > and have no effects except the return value. > > As you note, running forever *is* an effect. Therefore, `funct' is > not `const'. Therefore, the const-detection code should not detect > this case. It could be conservative by not including any function > with a loop (including a goto), or a function call. (Because a Thats what my finitary detection code does. Except that it allows calls to other const functions (that are guaranteed to be finitary) > function call could indicate recursion. I guess you could technically > ignore function calls; if that's the way by which you get infinite > looping then you'll get a stack overflow, which is undefined behavior, > which means that you can do anything you want. But, I think it would > be better to treat function calls like potential loops.) Recursive calls to function itself are detected as calls to nonconst function, so it behaves exactly like you suggest. > > Some other attribute (I think this is the `pure' attribute) *does* > apply to such functions. It says that this function may have loop > forever, but is guaranteed to return the same value whenever it is > called with the same arguments, and does not affect global memory. My current implementation is to handle "pure" functions as const functions with one extra input parametter (memory). So function will get removed too. Thats way I am documenting it in the patch and I think this is clean interpretation as long as it is documented in this way. We probably don;t have to worry much about optimizing calls to infinite functions. Needless to say that I don't see clean way how to avoid CSE to removing such functions. In future I would like to implement some data structure collecting information about function. I think it can contain bitmask of set registers, so some registers that are not set in called functions may be kept alive across function call to reduce non caller save register pressure. It also can contain flag "modify memory" that can be detected even for (possibly) infinite functions and CSE can consult it and flush tables only whenpresent. So call will look like as normal call (not CONST_CALL) so it will not be CSeed and loop optimized, but CSE will be still improved. (later we possibly might prepare exact list of modified/read memory addreses when easily determinable to improve CSE even more) But I still don't know how to associate such datastructure with function call. May I rely on the fact that function call insn numbers don't cahnge? (so calls.c may do the trick in separate array?) > So, you can turn `funct (1) + funct (1)' into `2 * funct(1)', or even > `funct (1)', if you're not using the value. > > (BTW, technically, your program has undefined behavior because `b' > will overflow. If you made `b' an unsigned int, the behavior would be > defined.) OK. It was meant just as demonstration. Sorry for the bug :) Honza > > -- > Mark Mitchell mark@codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com > From gcc-return-9354-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 14:55:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25933 invoked by alias); 23 Aug 1999 14:55:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25917 invoked from network); 23 Aug 1999 14:55:43 -0000 Received: from ss1000.ms.mff.cuni.cz (root@195.113.19.221) by egcs.cygnus.com with SMTP; 23 Aug 1999 14:55:43 -0000 Received: from u-sl0.ms.mff.cuni.cz (IDENT:jhub6202@u-sl0.ms.mff.cuni.cz [195.113.16.50]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id QAA21510; Mon, 23 Aug 1999 16:55:36 +0200 Received: from localhost (jhub6202@localhost) by u-sl0.ms.mff.cuni.cz (8.8.8/8.8.8) with SMTP id QAA08640; Mon, 23 Aug 1999 16:55:36 +0200 X-Authentication-Warning: u-sl0.ms.mff.cuni.cz: jhub6202 owned process doing -bs Date: Mon, 23 Aug 1999 16:55:36 +0200 (MET DST) From: Jan Hubicka X-Sender: jhub6202@u-sl0.ms.mff.cuni.cz To: John Wehle cc: egcs@egcs.cygnus.com, law@cygnus.com Subject: Re: New const function detection code and infinite loops. In-Reply-To: <199908230504.BAA22043@jwlab.FEITH.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 23 Aug 1999, John Wehle wrote: > > int funct(int b) > > { > > while(b&1) b+=2; > > return b; > > } > > main() > > { > > funct(1); > > } > > despite the fact, that function is complette nonsence, it still contains > > infinite loop (for certain input values), but will be marked as const by > > the detection code. So this program will terminate. Maybe this is ANSI-C > > conforming, but I don't believe so. > > I'm not following you. Are you saying that the program may be ANSI-C > conforming, or the new behavior of the compiler? I believe that marking > the function as const allows CSE to remove * redundant * calls which This is nor true. CSE hapilly removes call as long as return value is dead. If we modify CSE in way you suggest, we might get around the problem. But I don't think it is trivial task. At least following function: main() { funct(1); funct(1); } can be optimized to one call, but function: main() { funct(2); funct(1); } can not. This also contradict way CSE works. So I think better way to get around is to keep current behaviour on const functions and add the separate structure as I suggest. > means that the infinite loop will still occur for certain inputs, just > not as many infinite loops as would otherwise happen. I'm not sure in > what situation having fewer infinite loops for a given input creates a > problem unless you are thinking of situations where an external event > is causing control to leave the loop in which cause the loop may be > quite deliberate and perhaps should be marked volatile. I am not ANSI-C expert. If ANSI-C requires infinite loops to be volatile, we've won. But as pure programmer I would never come with idea to mark such loop as volatile and would be surprised to have my program finite. Honza > > -- John > ------------------------------------------------------------------------- > | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | > | John Wehle | Fax: 1-215-540-5495 | | > ------------------------------------------------------------------------- > From gcc-return-9355-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 15:00:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27527 invoked by alias); 23 Aug 1999 15:00:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27466 invoked from network); 23 Aug 1999 15:00:18 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 23 Aug 1999 15:00:18 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id HAA27175; Mon, 23 Aug 1999 07:59:32 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id HAA17860; Mon, 23 Aug 1999 07:59:27 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id HAA29163; Mon, 23 Aug 1999 07:59:27 -0700 Message-Id: <199908231459.HAA29163@atrus.synopsys.com> Subject: Re: gdb 4.17.0.13 is released. To: hjl@varesearch.com (H.J. Lu) Date: Mon, 23 Aug 99 7:59:27 PDT Cc: linux-gcc@vger.rutgers.edu, egcs@egcs.cygnus.com, libc-hacker@sourceware.cygnus.com, kjahds@kjahds.com, lmfken@lmf.ericsson.se, mat@lcs.mit.edu, doughera@lafcol.lafayette.edu, brian@mathworks.com, imp@village.org, meissner@cygnus.com, rfg@monkeys.com, linux-binutils-in@polstra.com, galenh@micron.net, ralf@mailhost.uni-koblenz.de, linas@linas.org In-Reply-To: <19990821205116.734FF3FC1@varesearch.com>; from "H.J. Lu" at Aug 21, 99 1:51 pm X-Mailer: ELM [version 2.3 PL11] HJ Lu writes: > This is the beta release of gdb 4.17.0.13, which is based on gdb 4.17 > plus Linux/x86 hardware watchpoint/FPU, glibc 2 pthread and Linux/PPC > support. Given that 4.18 is the current gdb release, why are you releasing a fork off of the old version? From gcc-return-9356-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 15:13:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 253 invoked by alias); 23 Aug 1999 15:13:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 172 invoked from network); 23 Aug 1999 15:13:39 -0000 Received: from gw.varesearch.com (HELO oxygen.su.varesearch.com) (@209.81.8.2) by egcs.cygnus.com with SMTP; 23 Aug 1999 15:13:39 -0000 Received: from hydrogen.su.varesearch.com ([10.1.0.1] helo=varesearch.com) by oxygen.su.varesearch.com with esmtp (Exim 2.12 #6) id 11Ivjm-0003p9-00; Mon, 23 Aug 1999 08:10:18 -0700 Received: by varesearch.com (Postfix, from userid 561) id 33ED03FC1; Mon, 23 Aug 1999 08:08:59 -0700 (PDT) Subject: Re: gdb 4.17.0.13 is released. To: jbuck@synopsys.COM (Joe Buck) Date: Mon, 23 Aug 1999 08:08:59 -0700 (PDT) Cc: hjl@varesearch.com (H.J. Lu), linux-gcc@vger.rutgers.edu, egcs@egcs.cygnus.com, libc-hacker@sourceware.cygnus.com, kjahds@kjahds.com, lmfken@lmf.ericsson.se, mat@lcs.mit.edu, doughera@lafcol.lafayette.edu, brian@mathworks.com, imp@village.org, meissner@cygnus.com, rfg@monkeys.com, linux-binutils-in@polstra.com, galenh@micron.net, ralf@mailhost.uni-koblenz.de, linas@linas.org In-Reply-To: <199908231459.HAA29163@atrus.synopsys.com> from "Joe Buck" at Aug 23, 1999 07:59:27 AM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990823150859.33ED03FC1@varesearch.com> From: hjl@varesearch.com (H.J. Lu) > > HJ Lu writes: > > > This is the beta release of gdb 4.17.0.13, which is based on gdb 4.17 > > plus Linux/x86 hardware watchpoint/FPU, glibc 2 pthread and Linux/PPC > > support. > > Given that 4.18 is the current gdb release, why are you releasing a > fork off of the old version? > > Have you tried gdb 4.18 on Linux? It lacks many important features added/fixed in gdb 4.17.0.x. People have been working on it. But it may not be there until 4.19. So for the time being, Linux has to use gdb 4.17.0.x if you want to debug thread, FPU and reliable hardware watchpoint on x86. BTW, I am working a patch for AMD new chip. I will make 4.17.0.14 after I get confirmation. -- H.J. Lu (hjl@gnu.org) From gcc-return-9357-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 15:26:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4540 invoked by alias); 23 Aug 1999 15:26:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4516 invoked from network); 23 Aug 1999 15:26:56 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 23 Aug 1999 15:26:56 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id IAA28685; Mon, 23 Aug 1999 08:26:21 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id IAA22091; Mon, 23 Aug 1999 08:26:20 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id IAA29418; Mon, 23 Aug 1999 08:26:19 -0700 Message-Id: <199908231526.IAA29418@atrus.synopsys.com> Subject: Re: gdb 4.17.0.13 is released. To: hjl@varesearch.com (H.J. Lu) Date: Mon, 23 Aug 99 8:26:19 PDT Cc: jbuck@synopsys.com, hjl@varesearch.com, linux-gcc@vger.rutgers.edu, egcs@egcs.cygnus.com, libc-hacker@sourceware.cygnus.com, kjahds@kjahds.com, lmfken@lmf.ericsson.se, mat@lcs.mit.edu, doughera@lafcol.lafayette.edu, brian@mathworks.com, imp@village.org, meissner@cygnus.com, rfg@monkeys.com, linux-binutils-in@polstra.com, galenh@micron.net, ralf@mailhost.uni-koblenz.de, linas@linas.org In-Reply-To: <19990823150859.33ED03FC1@varesearch.com>; from "H.J. Lu" at Aug 23, 99 8:08 am X-Mailer: ELM [version 2.3 PL11] I wrote: > > Given that 4.18 is the current gdb release, why are you releasing a > > fork off of the old version? HJ writes: > Have you tried gdb 4.18 on Linux? It lacks many important features > added/fixed in gdb 4.17.0.x. Just the same, gdb 4.18 has a number of bug fixes and other improvements. Unless you plan to create a permanent fork, life will be easier if you manage to create patches off of 4.18 (including some of your 4.17.0.x features not included in 4.18); this will, I think, make it easier for the gdb team to eventually include your changes. I notice that you didn't include the gdb maintainance address on your announcement. Was that an accident? From gcc-return-9358-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 15:34:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6912 invoked by alias); 23 Aug 1999 15:34:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6871 invoked from network); 23 Aug 1999 15:33:55 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 23 Aug 1999 15:33:55 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id JAA11549; Mon, 23 Aug 1999 09:33:01 -0600 X-Mailer: exmh version 2.0.2 To: Jan Hubicka cc: egcs@egcs.cygnus.com Subject: Re: New const function detection code and infinite loops. Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 23 Aug 1999 04:15:49 +0200. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Aug 1999 09:33:00 -0600 Message-ID: <11546.935422380@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > > > It is OK to remove call to function containing infinite loop? > > IMHO yes. A function with an infinite loop should never be const. > Thats true. But our new const detection code will happily mark such > function to be const. Thats wrong (because that function will be removed) Then that code is wrong. jeff From gcc-return-9359-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 15:34:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7243 invoked by alias); 23 Aug 1999 15:34:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7214 invoked from network); 23 Aug 1999 15:34:41 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 23 Aug 1999 15:34:41 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id JAA11570; Mon, 23 Aug 1999 09:33:50 -0600 X-Mailer: exmh version 2.0.2 To: egcs@egcs.cygnus.com cc: Igor Markov , Dimitri Papadopoulos Subject: Re: egcs/Solaris status Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 22 Aug 1999 21:28:12 CDT. <19990822212812.A16796@postal.thewrittenword.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Aug 1999 09:33:50 -0600 Message-ID: <11567.935422430@upchuck.cygnus.com> From: Jeffrey A Law In message <19990822212812.A16796@postal.thewrittenword.com>you write: > On Sun, Aug 22, 1999 at 05:01:51PM -0700, Igor Markov wrote: > > Our sysadmin was able to build 2.95.1 this time ---- > > apparently the problems arose because he was building 2.95.1 with 2.95 > > (and were solved by using egcs-1.1.2). > > > > thanks for other details -- they are very useful, > > We built 2.95.1 on Solaris 2.5.1, 2.6, 2.7/SPARC with Sun as/ld and > gcc 2.95 without any problems. However, trying to build 2.95.1 on > these platforms with the Sun v5.0 compiler fails: This is a bug in the Sun v5.0 compilers. Use some other compiler for bootstrapping jeff From gcc-return-9360-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 15:54:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13089 invoked by alias); 23 Aug 1999 15:53:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13061 invoked from network); 23 Aug 1999 15:53:57 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by egcs.cygnus.com with SMTP; 23 Aug 1999 15:53:57 -0000 Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id LAA10738; Mon, 23 Aug 1999 11:53:51 -0400 Received: from marc.watson.ibm.com (marc.watson.ibm.com [9.2.176.11]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id LAA18390; Mon, 23 Aug 1999 11:53:51 -0400 Received: from localhost by marc.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA33602; Mon, 23 Aug 1999 11:53:48 -0400 Message-Id: <9908231553.AA33602@marc.watson.ibm.com> To: brendan@dgs.monash.edu.au Cc: egcs mailing list , Cross-GCC Subject: Re: GCC: different OS targets. In-Reply-To: Message from Brendan Simon of "Mon, 23 Aug 1999 17:36:21 +1000." <37C0F9F5.FC29C7D3@dgs.monash.edu.au> Date: Mon, 23 Aug 1999 11:53:48 -0400 From: David Edelsohn The PowerPC port of GCC can be configured for AIX or for SVR4. The SVR4 port allows an AIX-style calling convention as compatibility for a very old embedded PowerPC environment that Cygnus once produced. One cannot build a single compiler for full support of both ABIs. Linux, eABI, Solaris, and SysV are all SVR4 variants and can be selected with a command-line option to a single compiler. David From gcc-return-9361-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 16:00:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15430 invoked by alias); 23 Aug 1999 16:00:34 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15385 invoked from network); 23 Aug 1999 16:00:29 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 23 Aug 1999 16:00:29 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id JAA11840; Mon, 23 Aug 1999 09:59:32 -0600 X-Mailer: exmh version 2.0.2 To: Dimitri PAPADOPOULOS-ORFANOS cc: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 23 Aug 1999 09:08:32 +0200. <199908230708.JAA09852@orcanie.shfj.cea.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Aug 1999 09:59:31 -0600 Message-ID: <11837.935423971@upchuck.cygnus.com> From: Jeffrey A Law > OK. Solaris tools may be buggy, but GCC is supposed to work on > Solaris. To a point. There's only so much we can do with buggy vendor tools. In fact the status of the Solaris linker is such that no matter what we do the tools will not work. ie, if we fix one bug all we do is introduce another because of lameness in the Sun tools -- there is currently no way to win. jeff From gcc-return-9362-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 16:04:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16545 invoked by alias); 23 Aug 1999 16:04:06 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16528 invoked from network); 23 Aug 1999 16:04:05 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 23 Aug 1999 16:04:05 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id KAA11873; Mon, 23 Aug 1999 10:02:26 -0600 X-Mailer: exmh version 2.0.2 To: jason andrade cc: gcc@gcc.gnu.org Subject: Re: direct mirror for australia Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 23 Aug 1999 11:21:20 +1000. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Aug 1999 10:02:25 -0600 Message-ID: <11870.935424145@upchuck.cygnus.com> From: Jeffrey A Law In message you wri te: > > hi, > > we are now directly mirroring gcc from sourceware.egcs.com > daily here at aarnet's mirror site in australia > > ftp://mirror.aarnet.edu.au/pub/egcs/ Thanks. Added. jeff From gcc-return-9363-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 16:09:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18701 invoked by alias); 23 Aug 1999 16:09:34 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18657 invoked from network); 23 Aug 1999 16:09:31 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 23 Aug 1999 16:09:31 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.9.3/8.9.3) with ESMTP id JAA25662; Mon, 23 Aug 1999 09:14:46 -0700 To: jhub6202@ss1000.ms.mff.cuni.cz Cc: john@feith.com, egcs@egcs.cygnus.com, law@cygnus.com Subject: Re: New const function detection code and infinite loops. In-Reply-To: References: <19990823000203L.mitchell@codesourcery.com> X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990823091446I.mitchell@codesourcery.com> Date: Mon, 23 Aug 1999 09:14:46 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 23 >>>>> "Jan" == Jan Hubicka writes: Jan> My current implementation is to handle "pure" functions as Jan> const functions with one extra input parametter (memory). So Jan> function will get removed too. But that's a bug. This program is guaranteed not to call abort in ANSI C: void f() { while (1); } int main () { f(); abort (); } I think we need to find a way to solve this problem. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-9364-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 16:27:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24701 invoked by alias); 23 Aug 1999 16:27:53 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24686 invoked from network); 23 Aug 1999 16:27:51 -0000 Received: from ss1000.ms.mff.cuni.cz (root@195.113.19.221) by egcs.cygnus.com with SMTP; 23 Aug 1999 16:27:51 -0000 Received: from u-sl0.ms.mff.cuni.cz (IDENT:jhub6202@u-sl0.ms.mff.cuni.cz [195.113.16.50]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id SAA04756; Mon, 23 Aug 1999 18:27:45 +0200 Received: from localhost (jhub6202@localhost) by u-sl0.ms.mff.cuni.cz (8.8.8/8.8.8) with SMTP id SAA11286; Mon, 23 Aug 1999 18:27:45 +0200 X-Authentication-Warning: u-sl0.ms.mff.cuni.cz: jhub6202 owned process doing -bs Date: Mon, 23 Aug 1999 18:27:44 +0200 (MET DST) From: Jan Hubicka X-Sender: jhub6202@u-sl0.ms.mff.cuni.cz To: Mark Mitchell cc: john@feith.com, egcs@egcs.cygnus.com, law@cygnus.com Subject: Re: New const function detection code and infinite loops. In-Reply-To: <19990823091446I.mitchell@codesourcery.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 23 Aug 1999, Mark Mitchell wrote: > >>>>> "Jan" == Jan Hubicka writes: > > Jan> My current implementation is to handle "pure" functions as > Jan> const functions with one extra input parametter (memory). So > Jan> function will get removed too. > > But that's a bug. This program is guaranteed not to call abort in > ANSI C: > > void f() { > while (1); > } This is not "pure" function in definition I use (I agree that current detection code is broken in the same way as "const" detection). But "pure" function in my definition is function that don't have side effects and as Jeff noted, looping forever is side effect. > > int main () { > f(); > abort (); > } > > I think we need to find a way to solve this problem. Thats why I've done the finitarity prooving function and why I suggest futher divide functions into two classes (known to be finite and pure/const (with pure or const attribute or detected by the testing function) and known to be deterministics and not writting to memory (easilly detectable by the current code we have)). We can keep handling of pure/const functions as we do. The functions with no side effects may just have this information attached with tthem, normal non-cseable call will be emmited, but cse will simply look at additional informaton available for the call (I believe later we keep track of more such hints as I sugested in my other email) and not flush the tables. So code will be still improved, but function will not be subject of redudnant calls removing/loop optimizations as CONST_CALL functions are. I think looping forever functions are more hypotetcial then practical case, we don't need special atribute to represent such functions in sources. On the other hand, halting problem is undecidable (well, in fact theoretically decidable in our model of computation because our machines are finite), so when we can't prove finitarity we can still attach such attribute and improve code. Honza > > -- > Mark Mitchell mark@codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com > From gcc-return-9365-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 16:59:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29652 invoked by alias); 23 Aug 1999 16:58:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29603 invoked from network); 23 Aug 1999 16:58:43 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 23 Aug 1999 16:58:43 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id MAA10686; Mon, 23 Aug 1999 12:58:34 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id MAA22779; Mon, 23 Aug 1999 12:58:33 -0400 (EDT) Date: Mon, 23 Aug 1999 12:58:33 -0400 (EDT) From: John Wehle Message-Id: <199908231658.MAA22779@jwlab.FEITH.COM> To: mitchell@codesourcery.com Cc: law@cygnus.com, gcc@gcc.gnu.org, jhub6202@ss1000.ms.mff.cuni.cz Subject: Re: New const function detection code and infinite loops. Content-Type: text Mark Mitchell writes: > But that's a bug. This program is guaranteed not to call abort in > ANSI C: > > void f() { > while (1); > } > > int main () { > f(); > abort (); > } > > I think we need to find a way to solve this problem. The current const detection code in the mainline sources will not mark f as const since it is externally visable and void type. It will however mark f as const in the following example: static int f() { while (1); return 0; } int main () { f(); abort(); } I take it that this example is also guaranteed not to call abort according to the ANSI C standard? I can prepare a patch to fix the problem (Jan, let me know if you're already handling this). BTW, is it easily provable that a loop will always terminate, or must we simply avoid marking the function as const if any type of loop construct is present? I guess this raises for me a more general question of how loops (any type of loop) should be handled. Loops create delays (infinite loops merely create infinite delays :-). At what point is a delay considered an observable event that is part of the program's behavior and should not be changed by the compiler? Granted an infinite loop is somewhat a special case. -- John PS: I see that the egcs mail server was changed to reject posts while I was following this thread and bounced an earlier reply to the list. ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-9366-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 17:20:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 753 invoked by alias); 23 Aug 1999 17:20:02 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 738 invoked from network); 23 Aug 1999 17:20:01 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 23 Aug 1999 17:20:01 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.9.3/8.9.3) with ESMTP id KAA26437; Mon, 23 Aug 1999 10:25:14 -0700 To: john@feith.com Cc: law@cygnus.com, gcc@gcc.gnu.org, jhub6202@ss1000.ms.mff.cuni.cz Subject: Re: New const function detection code and infinite loops. In-Reply-To: <199908231658.MAA22779@jwlab.FEITH.COM> References: <199908231658.MAA22779@jwlab.FEITH.COM> X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990823102513Y.mitchell@codesourcery.com> Date: Mon, 23 Aug 1999 10:25:13 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 78 The current const detection code in the mainline sources will not mark f as const since it is externally visable and void type. It will however mark f as const in the following example: static int f() { while (1); return 0; } int main () { f(); abort(); } I take it that this example is also guaranteed not to call abort according to the ANSI C standard? That is my reading. Essentially, calling a function does not have special semantics; this code is essentially equivalent to: int main () { while (1); 0; abort (); } There is nothing in this program which has undefined behavior. So, I think that we must not call abort. I can prepare a patch to fix the problem (Jan, let me know if you're already handling this). BTW, is it easily provable that a loop will always terminate, or must we simply avoid marking the function as const if any type of loop construct is present? It's of course in general impossible to prove that a loop will terminate. But, some simple and common cases are provable. If the loop simply increments a counter, which is not written elsewhere, and checks that the counter is less than some value, and the counter will not overflow before it reaches this value, then it is guaranteed to terminate. I'm not sure it's worth worrying about here, though. I would vote for just bailing whenever a loop is seen, at least for now. The programmer can always use __attribute__ ((const)) if they really know what they're doing. I *can* imagine cases where doing the loop thing would be a win: int f(int x, int y) { while (x--) y *= y; return y; } which does repeated squaring, or some such, is a `const' function, and is guaranteed not to loop forever. I just doubt that detecting this case is the low-hanging fruit in terms of getting better code out of GCC. I guess this raises for me a more general question of how loops (any type of loop) should be handled. Loops create delays (infinite loops merely create infinite delays :-). At what point is a delay considered an observable event that is part of the program's behavior and should not be changed by the compiler? Granted an infinite loop is somewhat a special case. >From a standards point of view, it's not a sliding scale. The standard says nothing about time (although the C++ standard library does have a few complexity constraints on algorithms). (That's why bad optimizing compilers are just as correct as good optimizing compilers.) So the compiler can insert and remove delays as it sees fit. But, there's nothing in the standards that says a compiler can remove an infinite loop, or insert one; the constraint is that *eventually* the program must do what it supposed to do, and no more. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-9367-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 17:21:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1408 invoked by alias); 23 Aug 1999 17:21:20 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1384 invoked from network); 23 Aug 1999 17:21:18 -0000 Received: from windlord.stanford.edu (171.64.12.23) by egcs.cygnus.com with SMTP; 23 Aug 1999 17:21:18 -0000 Received: (qmail 2048 invoked by uid 50); 23 Aug 1999 17:21:12 -0000 To: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <11837.935423971@upchuck.cygnus.com> From: Russ Allbery In-Reply-To: Jeffrey A Law's message of "Mon, 23 Aug 1999 09:59:31 -0600" Date: 23 Aug 1999 10:21:11 -0700 Message-ID: Lines: 37 X-Mailer: Gnus v5.4.66/Emacs 19.34 Jeffrey A Law writes: > To a point. There's only so much we can do with buggy vendor tools. In > fact the status of the Solaris linker is such that no matter what we do > the tools will not work. ie, if we fix one bug all we do is introduce > another because of lameness in the Sun tools -- there is currently no > way to win. As an aside to this discussion, from an outside observer who's been planning on upgrading to gcc 2.95.1 and is having trouble following the scope and nature of this problem and the tradeoffs involved in configuring a Solaris host with GNU binutils vs. vendor binutils, could someone update with the details of this problem? It currently lists a problem with the dynamic linker on Solaris 7, but it sounds like this is yet a different problem, unless I'm not following the discussion even more badly than I thought. There is also a note on that page: | all ELF targets (SVR4, Solaris, etc.) | C++ support is significantly better on ELF targets if you use the GNU | linker; duplicate copies of inlines, vtables and template instantiations | will be discarded automatically. which I assume is related to this, but it sounds like Solaris is more badly broken than other ELF targets and possibly for additional reasons? Figuring out what platforms to use GNU binutils on and what platforms to use the vendor tools, and which specific tools to use on which platforms, has always been one of the most difficult parts of installing gcc. I really appreciate the web documentation; it's made it much easier this time around. -- Russ Allbery (rra@stanford.edu) From gcc-return-9368-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 17:33:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4738 invoked by alias); 23 Aug 1999 17:33:20 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4717 invoked from network); 23 Aug 1999 17:33:09 -0000 Received: from ss1000.ms.mff.cuni.cz (root@195.113.19.221) by egcs.cygnus.com with SMTP; 23 Aug 1999 17:33:09 -0000 Received: from u-sl0.ms.mff.cuni.cz (IDENT:jhub6202@u-sl0.ms.mff.cuni.cz [195.113.16.50]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id TAA06507; Mon, 23 Aug 1999 19:33:04 +0200 Received: from localhost (jhub6202@localhost) by u-sl0.ms.mff.cuni.cz (8.8.8/8.8.8) with SMTP id TAA13228; Mon, 23 Aug 1999 19:33:04 +0200 X-Authentication-Warning: u-sl0.ms.mff.cuni.cz: jhub6202 owned process doing -bs Date: Mon, 23 Aug 1999 19:33:03 +0200 (MET DST) From: Jan Hubicka X-Sender: jhub6202@u-sl0.ms.mff.cuni.cz To: Mark Mitchell cc: john@feith.com, law@cygnus.com, gcc@gcc.gnu.org Subject: Re: New const function detection code and infinite loops. In-Reply-To: <19990823102513Y.mitchell@codesourcery.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > It's of course in general impossible to prove that a loop will > terminate. But, some simple and common cases are provable. If the > loop simply increments a counter, which is not written elsewhere, and > checks that the counter is less than some value, and the counter will > not overflow before it reaches this value, then it is guaranteed to > terminate. I'm not sure it's worth worrying about here, though. I > would vote for just bailing whenever a loop is seen, at least for now. > The programmer can always use __attribute__ ((const)) if they really > know what they're doing. Yes, thats exactly what I am doing now. I will send the patch this evening as soon as I return from the library. This just votes for the importance of some extra warning I've already implemented. (I suggest -Whints and document it as enabling various hints detected by compiler to optimize the code). It may ask for adding const/pure attributes to functions that seems to be const/pure and have one of following properties: 1) can not be proved to be finite. 2) are used before defined. 3) are public. 4) are recursive. And user might from time to time enable this warning and think about using the attributes. Also might ask for adding noreturn attribute and doing some other stuff. (I already also have the noreturn detecting code - fairly easy and it match even in few places in gcc, where noreturn is used). > > I *can* imagine cases where doing the loop thing would be a win: > > int f(int x, int y) > { > while (x--) > y *= y; > return y; > } > > which does repeated squaring, or some such, is a `const' function, and > is guaranteed not to loop forever. I just doubt that detecting this > case is the low-hanging fruit in terms of getting better code out of > GCC. In gcc sources there are about 1/3 of 200 detected "pure" functions disabled (1 const function) because of possible infinite loop. Once I get around problem of detecting recursive calls (how can I detect from CALL_INSN that it is calling function itself) I think more of them will arise, because there are actually quite a lot recursive predicates in gcc. But I think it is ratio was can happily live with. Also I report only function that mets conditions described above, so some static functions are not counted to this ration. Honza From gcc-return-9369-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 18:00:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12810 invoked by alias); 23 Aug 1999 18:00:29 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12760 invoked from network); 23 Aug 1999 18:00:19 -0000 Received: from unknown (HELO flame.fireclick.com) (216.70.165.48) by egcs.cygnus.com with SMTP; 23 Aug 1999 18:00:19 -0000 Received: from steph (steph.fireclick.com. [192.168.254.103]) by flame.fireclick.com (8.9.3/8.8.7) with SMTP id KAA08275 for ; Mon, 23 Aug 1999 10:56:33 -0700 Reply-To: From: "Stephane Kasriel" To: Subject: Pre-built version of GCC for solaris 2.7? Date: Mon, 23 Aug 1999 10:58:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_01BEED56.77B12120" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0008_01BEED56.77B12120 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01BEED56.77B8C240" ------=_NextPart_001_0009_01BEED56.77B8C240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Sorry if this is not the proper mailing list. I was wondering if I could get a pre-built version of gcc for Solaris 2.7. We don't seem to have cc or CC on our sun box and can therefore not install gcc. Thank you very much Stephane Kasriel Fireclick, Inc. www.fireclick.com W: 650 917 7606 ------=_NextPart_001_0009_01BEED56.77B8C240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi,
     
    Sorry = if this is not=20 the proper mailing list. I was wondering if I could get a pre-built = version of=20 gcc for Solaris 2.7. We don't seem to have cc or CC on our sun box and = can=20 therefore not install gcc.
    Thank = you very=20 much
     
     
     
    Stephane Kasriel
    Fireclick, Inc.
    www.fireclick.com
    W: 650 917 7606
     
    ------=_NextPart_001_0009_01BEED56.77B8C240-- ------=_NextPart_000_0008_01BEED56.77B12120 Content-Type: text/x-vcard; name="Stephane Kasriel.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Stephane Kasriel.vcf" BEGIN:VCARD VERSION:2.1 N:Kasriel;Stephane FN:Stephane Kasriel NICKNAME:moi EMAIL;PREF;INTERNET:stephane@fireclick.com REV:19990821T013336Z END:VCARD ------=_NextPart_000_0008_01BEED56.77B12120-- From gcc-return-9370-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 18:06:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15037 invoked by alias); 23 Aug 1999 18:06:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15013 invoked from network); 23 Aug 1999 18:06:26 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 23 Aug 1999 18:06:26 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id UAA26130; Mon, 23 Aug 1999 20:05:13 +0200 (MET DST) Date: Mon, 23 Aug 1999 20:05:15 +0200 (MET DST) From: Gerald Pfeifer To: Stephane Kasriel cc: gcc@gcc.gnu.org Subject: Re: Pre-built version of GCC for solaris 2.7? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 23 Aug 1999, Stephane Kasriel wrote: > Sorry if this is not the proper mailing list. I was wondering if I > could get a pre-built version of gcc for Solaris 2.7. We don't seem to > have cc or CC on our sun box and can therefore not install gcc. Thank > you very much Please have a look at the documentation where I added exactly that piece of information a couple of days ago: http://gcc.gnu.org/install/specific.html Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9371-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 18:15:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16743 invoked by alias); 23 Aug 1999 18:15:11 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16728 invoked by uid 22784); 23 Aug 1999 18:15:05 -0000 From: Stan Shebs Newsgroups: cygnus.egcs Subject: Re: gdb 4.17.0.13 is released. Date: 23 Aug 1999 11:12:08 -0700 Organization: Cygnus Solutions Lines: 25 Message-ID: References: <199908231526.IAA29418@atrus.synopsys.com> NNTP-Posting-Host: andros.cygnus.com X-Newsreader: Gnus v5.3/Emacs 19.34 To: egcs@egcs.cygnus.com DJ-Gateway: from newsgroup cygnus.egcs Joe Buck writes: > I wrote: > > > Given that 4.18 is the current gdb release, why are you releasing a > > > fork off of the old version? > > HJ writes: > > Have you tried gdb 4.18 on Linux? It lacks many important features > > added/fixed in gdb 4.17.0.x. > > Just the same, gdb 4.18 has a number of bug fixes and other improvements. > Unless you plan to create a permanent fork, life will be easier if you > manage to create patches off of 4.18 (including some of your 4.17.0.x > features not included in 4.18); this will, I think, make it easier for the > gdb team to eventually include your changes. It's being worked on, but it's convenient to have the 4.17.x patch releases in the meantime. It would be more useful to get patches relative to 4.18 patches though - GDB is going through some major evolution, and moving patches forward is going to get harder and harder. But, it's free software, and if HJ wants to patch up old versions of GDB instead of improving the current version, nobody can stop him. Stan From gcc-return-9372-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 18:20:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17904 invoked by alias); 23 Aug 1999 18:20:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17879 invoked from network); 23 Aug 1999 18:19:59 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 23 Aug 1999 18:19:59 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA06568; Mon, 23 Aug 1999 11:19:54 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id LAA29284; Mon, 23 Aug 1999 11:19:54 -0700 (PDT) Date: Mon, 23 Aug 1999 11:19:54 -0700 (PDT) Message-Id: <199908231819.LAA29284@kankakee.wrs.com> To: gcc@gcc.gnu.org, mnaik@hss.hns.com Subject: Re: a suggestion for generating better code without -O in GCC > From: mnaik@hss.hns.com > To: gcc@gcc.gnu.org > Date: Sat, 21 Aug 1999 19:20:44 +0530 > I have a minor suggestion for improving the unoptimized code generated > The following output is produced: > The optimal output would be: This is nonsensical. > Would it be worthwhile to generate output 2 without optimization? No. From gcc-return-9373-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 18:23:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19297 invoked by alias); 23 Aug 1999 18:23:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19282 invoked from network); 23 Aug 1999 18:23:20 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 23 Aug 1999 18:23:20 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id LAA13832; Mon, 23 Aug 1999 11:20:09 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id LAA12814; Mon, 23 Aug 1999 11:20:07 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id LAA01095; Mon, 23 Aug 1999 11:20:07 -0700 Message-Id: <199908231820.LAA01095@atrus.synopsys.com> Subject: Re: New const function detection code and infinite loops. To: john@feith.com (John Wehle) Date: Mon, 23 Aug 99 11:20:07 PDT Cc: mitchell@codesourcery.com, law@cygnus.com, gcc@gcc.gnu.org, jhub6202@ss1000.ms.mff.cuni.cz In-Reply-To: <199908231658.MAA22779@jwlab.FEITH.COM>; from "John Wehle" at Aug 23, 99 12:58 pm X-Mailer: ELM [version 2.3 PL11] > The current const detection code in the mainline sources will not > mark f as const since it is externally visable and void type. It > will however mark f as const in the following example: > > static int f() { > while (1); > return 0; > } (It would be nice to issue a warning for this function, as it cannot return a value). > int main () { > f(); > abort(); > } > > I take it that this example is also guaranteed not to call abort according > to the ANSI C standard? Yes. People who have never programmed embedded systems often think that only programs that terminate are interesting, but it common in embedded systems to write processes that are intended to run forever. So a compiler definitely cannot change a loop that runs forever to one that does not! > I can prepare a patch to fix the problem (Jan, let me know if you're > already handling this). BTW, is it easily provable that a loop will > always terminate, or must we simply avoid marking the function as const > if any type of loop construct is present? There is no algorithm (it is proven that there is no algorithm) for detecting, in general, that a loop terminates. However, there are many special cases where it is trivial to prove that the loop terminates (e.g. simple for-loops) or that it cannot (the one in your example). So we should avoid marking the function as const if a loop construct is present, unless we know that the loop will always terminate. > I guess this raises for me a more general question of how loops (any type > of loop) should be handled. Loops create delays (infinite loops merely > create infinite delays :-). At what point is a delay considered an > observable event that is part of the program's behavior and should not > be changed by the compiler? Granted an infinite loop is somewhat a > special case. I think that only the infinite loop matters. RMS wanted to never remove empty loops because they might be used for timing, but there are better ways of doing timing loops. From gcc-return-9374-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 18:46:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23901 invoked by alias); 23 Aug 1999 18:46:54 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23886 invoked from network); 23 Aug 1999 18:46:51 -0000 Received: from ss1000.ms.mff.cuni.cz (root@195.113.19.221) by egcs.cygnus.com with SMTP; 23 Aug 1999 18:46:51 -0000 Received: from u-sl0.ms.mff.cuni.cz (IDENT:jhub6202@u-sl0.ms.mff.cuni.cz [195.113.16.50]) by ss1000.ms.mff.cuni.cz (8.9.3/8.8.8) with ESMTP id UAA12723; Mon, 23 Aug 1999 20:46:48 +0200 Received: from localhost (jhub6202@localhost) by u-sl0.ms.mff.cuni.cz (8.8.8/8.8.8) with SMTP id UAA15284; Mon, 23 Aug 1999 20:46:48 +0200 X-Authentication-Warning: u-sl0.ms.mff.cuni.cz: jhub6202 owned process doing -bs Date: Mon, 23 Aug 1999 20:46:48 +0200 (MET DST) From: Jan Hubicka X-Sender: jhub6202@u-sl0.ms.mff.cuni.cz To: Joe Buck cc: John Wehle , mitchell@codesourcery.com, law@cygnus.com, gcc@gcc.gnu.org Subject: Re: New const function detection code and infinite loops. In-Reply-To: <199908231820.LAA01095@atrus.synopsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > mark f as const since it is externally visable and void type. It > > will however mark f as const in the following example: > > > > static int f() { > > while (1); > > return 0; > > } > > (It would be nice to issue a warning for this function, as it cannot > return a value). I have the noreturn detection code, so i can warn for nonvoid functions returning value if this is considered to be usefull. At the other hand,such warning will arise for many "int main" functions. Maybe these can be taken as exception? At least we can print warning (or error) when nonvoid function have noreturn attribute. Similary for void functions having const or pure attribute (this I've already implemented) Honza From gcc-return-9375-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 18:48:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24866 invoked by alias); 23 Aug 1999 18:48:34 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24842 invoked from network); 23 Aug 1999 18:48:32 -0000 Received: from merganser.its.uu.se (130.238.6.236) by egcs.cygnus.com with SMTP; 23 Aug 1999 18:48:31 -0000 Received: from uria.its.uu.se ([130.238.7.14]:3302 "HELO anoh0733.STUDENT.UU.SE") by merganser.its.uu.se with SMTP id convert rfc822-to-8bit; Mon, 23 Aug 1999 20:46:38 +0200 From: Anders.Ohrt@home.se (=?ISO-8859-1?Q?Anders_=D6hrt?=) To: gcc@gcc.gnu.org Subject: ELF support in windows Date: Mon, 23 Aug 1999 18:47:37 GMT Message-ID: <37c29736.2029668@mail.student.uu.se> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT I need ELF support under windows, and wrote to Mumit Khan who pointed me here... I'm developing an OS, and all code must be in ELF... I have a debian system also, but feel more comportable in NT (for now atleast). What I need is just gcc and ld, nothing more... From gcc-return-9376-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 19:31:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32570 invoked by alias); 23 Aug 1999 19:31:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32555 invoked from network); 23 Aug 1999 19:31:45 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 23 Aug 1999 19:31:45 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA17283; Mon, 23 Aug 1999 12:31:44 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id MAA29359; Mon, 23 Aug 1999 12:31:44 -0700 (PDT) Date: Mon, 23 Aug 1999 12:31:44 -0700 (PDT) Message-Id: <199908231931.MAA29359@kankakee.wrs.com> To: edA-qa@disemia.com, gcc@gcc.gnu.org Subject: Re: How is 'this' passed to member function calls? This is like saying, I have this loaded shotgun here, and if I angle it this way into my mouth, will it work? Well, yes, basically, if you do it right. I, of course, recommend not doing that, even if it might work. It is painful for a C++ programmer to watch you do that. We should not help you... Couldn't use use a templated static member function to do what you want or something? > From: "edA-qa mort-ora-y" > Date: Sun, 22 Aug 1999 09:38:36 -0600 > I have a situation where I want to directly call member functions, > via a pointer to the member function and having an object pointer. From gcc-return-9377-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 20:03:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2672 invoked by alias); 23 Aug 1999 20:02:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2657 invoked from network); 23 Aug 1999 20:02:58 -0000 Received: from smtp.interlog.com (root@207.34.202.37) by egcs.cygnus.com with SMTP; 23 Aug 1999 20:02:58 -0000 Received: from crjnt2 (cj.interlog.com [199.212.157.174]) by smtp.interlog.com (8.9.1/8.9.1) with SMTP id QAA04418; Mon, 23 Aug 1999 16:02:41 -0400 (EDT) Message-Id: <3.0.32.19990823160419.009d03e0@mail.interlog.com> X-Sender: cj@mail.interlog.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 23 Aug 1999 16:04:22 -0400 To: , From: "Christopher R. Jones" Subject: Re: Pre-built version of GCC for solaris 2.7? Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" See www.sunfreeware.com for a number of binaries for both Sparc and Intel versions of Solaris 2.7. At 10:58 AM 8/23/99 -0700, Stephane Kasriel wrote: >>>> Hi,Arial7070,6c6c,7979 Sorry if this is not the proper mailing list. I was wondering if I could get a pre-built version of gcc for Solaris 2.7. We don't seem to have cc or CC on our sun box and can therefore not install gcc. Thank you very much Stephane Kasriel Fireclick, Inc. www.fireclick.com W: 650 917 7606 Attachment Converted: "c:\program files\eudora\attach\Stephane Kasriel.vcf" Arial7070,6c6c,7979 Christopher R. Jones, P.Eng. 14 Oneida Avenue Toronto, Ontario M5J 2E3 Tel. 416 203-7465 Fax. 416 203-3044 Email cj@interlog.com From gcc-return-9378-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 20:06:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3698 invoked by alias); 23 Aug 1999 20:06:40 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3648 invoked from network); 23 Aug 1999 20:06:38 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 23 Aug 1999 20:06:38 -0000 Received: (qmail 2513 invoked by alias); 23 Aug 1999 20:06:33 -0000 Received: (qmail 2503 invoked from network); 23 Aug 1999 20:06:33 -0000 Received: from peshwari.cygnus.co.uk (HELO cygnus.co.uk) (jlarmour@194.130.39.29) by dns.cygnus.co.uk with SMTP; 23 Aug 1999 20:06:33 -0000 Message-ID: <37C1A9C5.ACE8F022@cygnus.co.uk> Date: Mon, 23 Aug 1999 20:06:29 +0000 From: Jonathan Larmour Organization: Cygnus Solutions X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Roger Williams CC: gcc@gcc.gnu.org, ecos-discuss , Cross-GCC Subject: Re: GCC: different OS targets. References: <37C099D3.C0BE0BC5@dgs.monash.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roger Williams wrote: > > >>>>> Brendan Simon writes: > > > I would like to be able to build gcc _ONCE_ for powerpc-eabi and > > be able to build the RTEMS, eCos (or any other OS) libraries and > > install them in an appropriate place. > > Yes indeed, this would be *very* helpful. I'm currently developing > MPC8xx code for no-OS, Linux, and Neutrino, and I have separate > development installations for each of these. I want to start working > with eCos, but I dread the thought of yet another set of powerpc-eabi > tools and libraries... You only need a standard powerpc-eabi toolchain for eCos, not a special one. The only constraint is that it must be post egcs-1.1.2. gcc-2.95.1 should work absolutely fine. As Bart Veer mentioned on ecos-discuss, things like thread-safe C++ exceptions require knowledge of the OS. However, to be honest, I think that's all there is. If you were not interested in thread-safe C++ exceptions - and many RTOS folks aren't - then in general I don't think there is any technical reason for different toolchain targets, apart from convenience. But this isn't just convenience for the OS developers, but also for the compiler developers. If you consolidated two similar toolchains into one, e.g. powerpc-eabi and powerpc-elf, then this suddenly means you have to build (at least) twice the number of multi-libs when building a completely generic set of tools, in order to support the two ABIs. If you look at the current powerpc-eabi compiler, you'll see that it already has 25 multi-libs, which means building versions of libgcc, newlib, libio, and libstdc++ 25 times, which is already painful and disk-intensive. I am hoping we will eventually be able to make some changes to gcc that will reduce it's dependency on the run-time side at gcc compile-time. But don't hold your breath :-/. BTW, for these reasons, making eCos use the standard toolchain isn't as clean as we would like. We override the linker script, and use -nostdlib to avoid picking up the default crt0's and libc. I don't know how easy it is for other OS's to do something similar though. Jifl -- Cygnus Solutions, 35 Cambridge Place, Cambridge, UK. Tel: +44 (1223) 728762 "I used to have an open mind but || Get yer free open source RTOS's here... my brains kept falling out." || http://sourceware.cygnus.com/ecos Help fight spam! http://spam.abuse.net/ These opinions are all my own fault From gcc-return-9379-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 20:29:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8303 invoked by alias); 23 Aug 1999 20:29:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8288 invoked from network); 23 Aug 1999 20:29:12 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 23 Aug 1999 20:29:12 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id QAA05618 for ; Mon, 23 Aug 1999 16:29:10 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (burley@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id QAA26672 for ; Mon, 23 Aug 1999 16:27:16 -0400 (EDT) Received: (qmail 18847 invoked by uid 500); 23 Aug 1999 20:24:46 -0000 Date: 23 Aug 1999 20:24:46 -0000 Message-ID: <19990823202446.18846.qmail@deer> To: rra@stanford.edu CC: egcs@egcs.cygnus.com cc: craig@jcb-sc.com In-reply-to: (message from Russ Allbery on 23 Aug 1999 10:21:11 -0700) Subject: Re: egcs/Solaris status References: <11837.935423971@upchuck.cygnus.com> >Figuring out what platforms to use GNU binutils on and what platforms to >use the vendor tools, and which specific tools to use on which platforms, >has always been one of the most difficult parts of installing gcc. I >really appreciate the web documentation; it's made it much easier this >time around. Thanks for saying that on this list. Gerald, Jeff, and many others, certainly deserve a big round of applause for the GCC/EGCS web site, IMO. Even as a developer, I find the ease of access of the web site, versus having to download and build texinfo documentation myself, has definitely made my life easier -- I can imagine how much more end users are benefited. tq vm, (burley) From gcc-return-9380-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 20:31:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9629 invoked by alias); 23 Aug 1999 20:31:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9614 invoked from network); 23 Aug 1999 20:31:42 -0000 Received: from force.stwing.upenn.edu (130.91.120.95) by egcs.cygnus.com with SMTP; 23 Aug 1999 20:31:42 -0000 Received: from pc-rchapman (ns2.divi.com [199.97.190.20]) by force.stwing.upenn.edu (8.8.5/8.8.8) with ESMTP id QAA14493 for ; Mon, 23 Aug 1999 16:31:40 -0400 (EDT) Message-Id: <4.2.0.58.19990823132909.00a5e220@kms> X-Sender: hchapman@stwing.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 (demo) Date: Mon, 23 Aug 1999 13:31:20 -0700 To: gcc@gcc.gnu.org From: Richard Harvey Chapman Subject: scope issue Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Is there a correct output for the following? int main ( void ) { int x=9; printf ("%d\n", (x + x++) - --x); printf ("%d %d\n", ++x, x++); } I believe that it should be: 9 10 10 but different compilers have given different answers. R. From gcc-return-9381-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 20:41:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11000 invoked by alias); 23 Aug 1999 20:41:53 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10981 invoked from network); 23 Aug 1999 20:41:47 -0000 Received: from dbcci.com (HELO portabella.synapsysinc.com) (206.161.147.2) by egcs.cygnus.com with SMTP; 23 Aug 1999 20:41:47 -0000 Received: from dvv.org (toadstool [206.161.147.21]) by portabella.synapsysinc.com (8.9.1/8.9.1/Synapsys 98/06/19) with ESMTP id QAA03710; Mon, 23 Aug 1999 16:41:09 -0400 (EDT) Message-ID: <37C1B1E4.4FA8B09E@dvv.org> Date: Mon, 23 Aug 1999 16:41:08 -0400 From: Dima Volodin Organization: Huh? X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 i86pc) X-Accept-Language: ru, en MIME-Version: 1.0 To: Richard Harvey Chapman CC: gcc@gcc.gnu.org Subject: Re: scope issue References: <4.2.0.58.19990823132909.00a5e220@kms> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Richard Harvey Chapman wrote: > Is there a correct output for the following? No, there isn't. > int main ( void ) > { > int x=9; > > printf ("%d\n", (x + x++) - --x); > printf ("%d %d\n", ++x, x++); > } > > I believe that it should be: > 9 > 10 10 > > but different compilers have given different answers. > > R. Dima From gcc-return-9382-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 20:47:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12027 invoked by alias); 23 Aug 1999 20:47:02 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12005 invoked from network); 23 Aug 1999 20:46:58 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 23 Aug 1999 20:46:58 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id QAA16145 for ; Mon, 23 Aug 1999 16:45:21 -0400 Message-ID: <37C1B45E.7CF02F11@moberg.com> Date: Mon, 23 Aug 1999 20:51:42 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: C++ and 2.95.1--Any problems noted? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I just downloaded, compiled and installed 2.95.1 on a plain-vanilla x86 Linux Mandrake 6.0 system. The C library installed is glibc2.1.1pre2 compiled with egcs 1.1.2. The configure command I used was: ../src/configure --prefix=/usr --enable-shared --enable-threads I then did "make bootstrap" followed by "make install". Everything worked. Then, when I went to compile my C++ program, it died in linking with errors where it can't find: std::terminate(void) ostream& operator<< (ostream&, smanip const &) The program compiled and ran fine w/EGCS 1.1.2. Any ideas? I've been pulling my hair out with this all day. Note that if I use the standard egcs 1.1.2 installation that came preinstalled on Linux Mandrake, it gives me errors on std::terminate(), but not the operator<< thing. Thanks in advance. -- George T. Talbot P.S. Here's some of the output of the link phase, in case you're interested... g++ -o xml2sc hashtable.ot xmlparse.ot xmlrole.ot xmltok.ot rwlock.ot assoc.ot Attribute.ot MatchingVisitor.ot NamedElement.ot Symbol.ot Tag.ot ValueVisitor.ot XMLInputBuilder.ot XMLOutputVisitor.ot FileTag.ot LazyTag.ot DirTag.ot SettingsManager.ot TreeVisitor.ot TreeBuilder.ot OutputVisitor.ot SettingChangeNotifier.ot ServiceHeaderBuilder.ot ServiceImplBuilder.ot xml2cpp.ot TypeRegistry.ot cstringostream.ot ReferenceList.ot ComponentHeaderBuilder.ot ComponentImplBuilder.ot LinkTag.ot Service.ot Component.ot PrintFields.ot String.ot Threading_Linux.ot JavaServiceBuilder.ot -lpthread Attribute.ot: In function `CAttribute::CAttribute(CTag *, CString const &)': /home/george/working/mrc/tools/xml2sc/../../src/settingtree/Attribute.cpp:60: undefined reference to `std::terminate(void)' Attribute.ot: In function `CAttribute::CAttribute(CTag *, CSymbol const *)': /home/george/working/mrc/tools/xml2sc/../../src/settingtree/Attribute.cpp:65: undefined reference to `std::terminate(void)' Attribute.ot: In function `CAttribute::SetValue(long, char const *)': /home/george/working/mrc/tools/xml2sc/../../src/settingtree/Attribute.cpp:75: undefined reference to `std::terminate(void)' MatchingVisitor.ot: In function `CLinkTag type_info function': /home/george/working/mrc/tools/xml2sc/../../src/settingtree/MatchingVisitor.cpp(.text+0xb2): undefined reference to `std::terminate(void)' /home/george/working/mrc/tools/xml2sc/../../src/settingtree/MatchingVisitor.cpp(.text+0x2f1): undefined reference to `std::terminate(void)' MatchingVisitor.ot(.text+0x381):/home/george/working/mrc/tools/xml2sc/../../src/settingtree/MatchingVisitor.cpp: more undefined references to `std::terminate(void)' follow XMLOutputVisitor.ot: In function `CXMLOutputVisitor type_info function': /home/george/working/mrc/tools/xml2sc/../../src/xmlparse/XMLOutputVisitor.cpp(.text+0x2ae): undefined reference to `ostream & operator<<(ostream &, smanip const &)' /home/george/working/mrc/tools/xml2sc/../../src/xmlparse/XMLOutputVisitor.cpp(.text+0x2c0): undefined reference to `ostream & operator<<(ostream &, smanip const &)' XMLOutputVisitor.ot: In function `CXMLOutputVisitor::VisitTag(CTag *)': /home/george/working/mrc/tools/xml2sc/../../src/xmlparse/XMLOutputVisitor.cpp:230: undefined reference to `ostream & operator<<(ostream &, smanip const &)' /home/george/working/mrc/tools/xml2sc/../../src/xmlparse/XMLOutputVisitor.cpp:230: undefined reference to `ostream & operator<<(ostream &, smanip const &)' /home/george/working/mrc/tools/xml2sc/../../src/xmlparse/XMLOutputVisitor.cpp:268: undefined reference to `ostream & operator<<(ostream &, smanip const &)' XMLOutputVisitor.ot:/home/george/working/mrc/tools/xml2sc/../../src/xmlparse/XMLOutputVisitor.cpp:268: more undefined references to `ostream & operator<<(ostream &, smanip const &)' follow From gcc-return-9383-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 21:41:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20832 invoked by alias); 23 Aug 1999 21:41:20 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20815 invoked from network); 23 Aug 1999 21:41:17 -0000 Received: from ronispc.chem.mcgill.ca (0@132.206.20.6) by egcs.cygnus.com with SMTP; 23 Aug 1999 21:41:17 -0000 Received: (from ronis@localhost) by ronispc.chem.mcgill.ca (8.9.3/8.9.3) id RAA14169; Mon, 23 Aug 1999 17:41:12 -0400 Date: Mon, 23 Aug 1999 17:41:12 -0400 Message-Id: <199908232141.RAA14169@ronispc.chem.mcgill.ca> X-Authentication-Warning: ronispc.chem.mcgill.ca: ronis set sender to ronis@ronispc.chem.mcgill.ca using -f From: David Ronis To: gcc@gcc.gnu.org Subject: Constants and -ffast-math Reply-to: ronis@onsager.chem.mcgill.ca I'm not sure that gcc is really my problem, but I have some messy floating point code that isn't working. Some debugging sessions have started me thinking that perhaps I'm getting into trouble with round-off error. I have all floating-point's declared as doubles, except for explicit floating point constants (like 1.0 or 0.0). I was under the impression that 1.0 defaults to a double; does this change with --fast-math? It shouldn't, but I'm running out of ideas. As long as I'm at it, could someone amplify on what exactly --fast-math does, beyond the information in the gcc info docs. Thanks David From gcc-return-9384-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 21:45:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22068 invoked by alias); 23 Aug 1999 21:45:05 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22053 invoked by uid 22784); 23 Aug 1999 21:45:04 -0000 From: Tom Tromey Newsgroups: cygnus.egcs Subject: Re: BUILDING JAVA 2.95 LIB Date: 23 Aug 1999 15:42:22 -0600 Organization: Cygnus Solutions Lines: 19 Message-ID: <87u2pquqbl.fsf@cygnus.com> References: <19990823015313.17370.rocketmail@web122.yahoomail.com> Reply-To: tromey@cygnus.com NNTP-Posting-Host: rtl.cygnus.com X-Zippy: Where does it go when you flush? X-Attribution: Tom X-Newsreader: Gnus v5.5/Emacs 20.2 To: egcs@egcs.cygnus.com DJ-Gateway: from newsgroup cygnus.egcs >>>>> "Alex" == sysadm writes: Alex> Any attempt to give ./configure fails , the configure Alex> exits immediatelly. cd to libjava then ./configure Alex> again fails. Why??? Do I need I source tree of Alex> gcc-2.95 Alex> somewhere and a decalration of it (to the libjava Alex> configure script)? Certainly Alex> /configure --help doesnt list that... When reporting libgcj bugs, please: 1. Use the correct address -- report the bugs to the libgcj bug list. 2. Read the online info first. You cannot configure libgcj in the source tree. You must use a separate build tree. Tom From gcc-return-9385-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 21:50:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23437 invoked by alias); 23 Aug 1999 21:50:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23422 invoked from network); 23 Aug 1999 21:50:55 -0000 Received: from mandrakesoft.mandrakesoft.com (216.71.84.35) by egcs.cygnus.com with SMTP; 23 Aug 1999 21:50:55 -0000 Received: from vador.mandrakesoft.com (dyn-1-1-069.Vin.dialup.oleane.fr [195.25.4.69]) by mandrakesoft.mandrakesoft.com (8.8.5/8.8.5) with ESMTP id QAA24621; Mon, 23 Aug 1999 16:47:14 -0500 Received: (from chmou@localhost) by vador.mandrakesoft.com (8.9.3/8.9.3/Chmouel/SMTP) id XAA05117; Mon, 23 Aug 1999 23:51:21 +0200 To: "George T. Talbot" Cc: gcc@gcc.gnu.org, Cooker Subject: Re: C++ and 2.95.1--Any problems noted? References: <37C1B45E.7CF02F11@moberg.com> X-no-archive: yes From: Chmouel Boudjnah Date: 23 Aug 1999 23:51:21 +0200 In-Reply-To: "George T. Talbot"'s message of "Mon, 23 Aug 1999 20:51:42 +0000" Message-ID: Lines: 33 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.1 (Arches) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "George T. Talbot" writes: > I just downloaded, compiled and installed 2.95.1 on a plain-vanilla x86 > Linux Mandrake 6.0 system. The C library installed is glibc2.1.1pre2 > compiled with egcs 1.1.2. > > The configure command I used was: > > ../src/configure --prefix=/usr --enable-shared --enable-threads > > I then did "make bootstrap" followed by "make install". Everything > worked. > > Then, when I went to compile my C++ program, it died in linking with > errors where it can't find: > > std::terminate(void) > ostream& operator<< (ostream&, smanip const &) > > The program compiled and ran fine w/EGCS 1.1.2. > > Any ideas? I've been pulling my hair out with this all day. Note that > if I use the standard egcs 1.1.2 installation that came preinstalled on > Linux Mandrake, it gives me errors on std::terminate(), but not the > operator<< thing. could you try with rpm of gcc-2.95 from cooker : http://www.linux-mandrake.com/cooker -- MandrakeSoft http://www.mandrakesoft.com/ --Chmouel From gcc-return-9386-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 21:52:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24330 invoked by alias); 23 Aug 1999 21:52:20 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24243 invoked from network); 23 Aug 1999 21:52:14 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 23 Aug 1999 21:52:14 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id RAA16784 for ; Mon, 23 Aug 1999 17:50:37 -0400 Message-ID: <37C1C3AB.552B357C@moberg.com> Date: Mon, 23 Aug 1999 21:56:59 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: -fnew-abi and C++? (was C++ and 2.95.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit OK...I found my problem with linking problems and C++. If I compile with the -fnew-abi option, I get link errors where it can't find functions like std::terminate(). Any idea on that one? GCC 2.95.1 -- George T. Talbot From gcc-return-9387-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 22:11:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27345 invoked by alias); 23 Aug 1999 22:11:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27328 invoked from network); 23 Aug 1999 22:11:22 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 23 Aug 1999 22:11:22 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id SAA17052; Mon, 23 Aug 1999 18:09:40 -0400 Message-ID: <37C1C822.2582E209@moberg.com> Date: Mon, 23 Aug 1999 22:16:02 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chmouel Boudjnah , gcc@gcc.gnu.org CC: Jason Merrill Subject: Re: C++ and 2.95.1--Any problems noted? References: <37C1B45E.7CF02F11@moberg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chmouel Boudjnah wrote: > > "George T. Talbot" writes: > > > I just downloaded, compiled and installed 2.95.1 on a plain-vanilla x86 > > Linux Mandrake 6.0 system. The C library installed is glibc2.1.1pre2 > > compiled with egcs 1.1.2. > > > > The configure command I used was: > > > > ../src/configure --prefix=/usr --enable-shared --enable-threads > > > > I then did "make bootstrap" followed by "make install". Everything > > worked. > > > > Then, when I went to compile my C++ program, it died in linking with > > errors where it can't find: > > > > std::terminate(void) > > ostream& operator<< (ostream&, smanip const &) > > > > The program compiled and ran fine w/EGCS 1.1.2. > > > > Any ideas? I've been pulling my hair out with this all day. Note that > > if I use the standard egcs 1.1.2 installation that came preinstalled on > > Linux Mandrake, it gives me errors on std::terminate(), but not the > > operator<< thing. > > could you try with rpm of gcc-2.95 from cooker : > > http://www.linux-mandrake.com/cooker OK. I just installed those RPM's and I get the same thing. If I use the -fnew-abi option, which I wanted to use to get the latest exception-handling model, I get the errors as I described in the last e-mail to the list. If I use the -fnew-exceptions option instead of -fnew-abi, the compiler fails with an internal compiler error. If I omit both -fnew-abi and -fnew-exceptions, the code compiles. However, I'm not sure whether it's using the right (thread safe) exception model or not. Jason Merrill: The reason I CC'd this to you, is that I wanted to ask if I need -fnew-exceptions or -fnew-abi for the thread-safe exception model under Linux. -- George T. Talbot P.S. The internal compiler error: [george@dhcp41 xml2sc]$ make g++ -c -Wall -ansi -pedantic -O3 -DNDEBUG -I. -I../.. -I../../include -D_GNU_SOURCE -D_REENTRANT -DPLATFORM_LINUX=1 -DEXPORT= -fno-implicit-templates -g -fnew-exceptions ../../src/settingtree/MatchingVisitor.cpp -o MatchingVisitor.ot ../../src/settingtree/MatchingVisitor.cpp: In method `void CMatchingVisitor::VisitTag(CTag *)': ../../src/settingtree/MatchingVisitor.cpp:278: Internal compiler error. ../../src/settingtree/MatchingVisitor.cpp:278: Please submit a full bug report. ../../src/settingtree/MatchingVisitor.cpp:278: See for instructions. make: *** [MatchingVisitor.ot] Error 1 [george@dhcp41 xml2sc]$ From gcc-return-9388-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 22:20:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29283 invoked by alias); 23 Aug 1999 22:20:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29268 invoked from network); 23 Aug 1999 22:20:23 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 23 Aug 1999 22:20:23 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA22963; Mon, 23 Aug 1999 15:20:21 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id PAA00933; Mon, 23 Aug 1999 15:20:20 -0700 To: "George T. Talbot" Cc: Chmouel Boudjnah , gcc@gcc.gnu.org Subject: Re: C++ and 2.95.1--Any problems noted? References: <37C1B45E.7CF02F11@moberg.com> <37C1C822.2582E209@moberg.com> From: Jason Merrill Date: 23 Aug 1999 15:20:20 -0700 In-Reply-To: "George T. Talbot"'s message of "Mon, 23 Aug 1999 22:16:02 +0000" Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> George T Talbot writes: > Jason Merrill: The reason I CC'd this to you, is that I wanted to ask > if I need -fnew-exceptions or -fnew-abi for the thread-safe exception > model under Linux. No. You just need to configure gcc with --enable-threads. -fnew-exceptions is more efficient, but it's also not complete in 2.95. Jason From gcc-return-9389-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 22:35:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31853 invoked by alias); 23 Aug 1999 22:34:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31837 invoked from network); 23 Aug 1999 22:34:50 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by egcs.cygnus.com with SMTP; 23 Aug 1999 22:34:50 -0000 Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id SAA11146; Mon, 23 Aug 1999 18:34:48 -0400 Received: from marc.watson.ibm.com (marc.watson.ibm.com [9.2.176.11]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id SAA08448; Mon, 23 Aug 1999 18:34:47 -0400 Received: from localhost by marc.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA39992; Mon, 23 Aug 1999 18:34:47 -0400 Message-Id: <9908232234.AA39992@marc.watson.ibm.com> To: "George T. Talbot" Cc: gcc@gcc.gnu.org Subject: Re: -fnew-abi and C++? (was C++ and 2.95.1) In-Reply-To: Message from "George T. Talbot" of "Mon, 23 Aug 1999 21:56:59 -0000." <37C1C3AB.552B357C@moberg.com> Date: Mon, 23 Aug 1999 18:34:47 -0400 From: David Edelsohn If you use the -fnew-abi option of G++, you need to BUILD libgcc and libstdc++ with that option. -fnew-abi is not a runtime option that you can select arbitrarily and co-exist with the old ABI. The new ABI affects mangling of C++ symbols. This is why -fnew-abi is waiting for a lot of functionality before it is enabled, because it will break compatibility with old object files and libraries. David From gcc-return-9390-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 22:41:40 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 167 invoked by alias); 23 Aug 1999 22:41:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 149 invoked from network); 23 Aug 1999 22:41:28 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 23 Aug 1999 22:41:28 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id SAA17402; Mon, 23 Aug 1999 18:39:50 -0400 Message-ID: <37C1CF34.A6004AD3@moberg.com> Date: Mon, 23 Aug 1999 22:46:12 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: David Edelsohn , gcc@gcc.gnu.org Subject: Re: -fnew-abi and C++? (was C++ and 2.95.1) References: <9908232234.AA39992@marc.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Edelsohn wrote: > > If you use the -fnew-abi option of G++, you need to BUILD libgcc > and libstdc++ with that option. -fnew-abi is not a runtime option that > you can select arbitrarily and co-exist with the old ABI. The new ABI > affects mangling of C++ symbols. This is why -fnew-abi is waiting for a > lot of functionality before it is enabled, because it will break > compatibility with old object files and libraries. > > David OK. Thanks for the heads up. I was only doing it because I wanted thread-safe exceptions, which Jason Merrill at Cygnus says I get when compiling gcc with --enable-threads, so I don't need -fnew-abi after all. -- George T. Talbot From gcc-return-9391-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 23:17:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4274 invoked by alias); 23 Aug 1999 23:17:01 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4241 invoked from network); 23 Aug 1999 23:16:59 -0000 Received: from falla.videotron.net (205.151.222.106) by egcs.cygnus.com with SMTP; 23 Aug 1999 23:16:59 -0000 Received: from binaire.cx ([24.200.35.156]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.03.02.17.58.p5) with ESMTP id <0FGX00JIBY053K@falla.videotron.net> for egcs@egcs.cygnus.com; Mon, 23 Aug 1999 19:16:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by binaire.cx (8.9.3/8.9.3) id TAA14934 for egcs@egcs.cygnus.com; Mon, 23 Aug 1999 19:16:52 -0400 Date: Mon, 23 Aug 1999 23:08:01 +0000 From: Binaire Subject: GCC-2.95.x and error compiling kernel module vmware and gart To: egcs@egcs.cygnus.com Message-id: <99082323165200.14902@binaire.cx> MIME-version: 1.0 X-Mailer: KMail [version 1.0.26] Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 8bit Hi , I had a problem when compiling non officical kernel module like the one with vmware and gart-glx with gcc-2.95.x When not including -I/usr/src/linux/include in the makefile i have a tone of errors from incompatible types ... I have track down the problem to usr/lib/gcc-lib/....../2.95.1/include/gnu/types.h This file is supposed to be a wrapper to fixe __FD_ZERO bug for glibc-1.x Even that i have glibc-2.1.2pre the preprocessor seem to include this file when i don't define -I/usr/src/linux/include and this give me error on compililation Removing this file from my system fixe this error So is there any error in types.h ? #if defined(__FD_ZERO) && !defined(__GLIBC__) In features.h from glibc i have : #define __GLIBC__ 2 #define __GLIBC_MINOR__ 1 -vhq From gcc-return-9392-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 23 23:37:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7157 invoked by alias); 23 Aug 1999 23:37:36 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7142 invoked from network); 23 Aug 1999 23:37:34 -0000 Received: from field.videotron.net (205.151.222.108) by egcs.cygnus.com with SMTP; 23 Aug 1999 23:37:34 -0000 Received: from binaire.cx ([24.200.35.156]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.03.02.17.58.p5) with ESMTP id <0FGX00I55YY8D2@field.videotron.net> for egcs@egcs.cygnus.com; Mon, 23 Aug 1999 19:37:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by binaire.cx (8.9.3/8.9.3) id TAA15088 for egcs@egcs.cygnus.com; Mon, 23 Aug 1999 19:37:19 -0400 Date: Mon, 23 Aug 1999 23:37:01 +0000 From: Binaire Subject: GCC-2.95.x and error compiling kernel module vmware and gart To: egcs@egcs.cygnus.com Message-id: <99082323371900.15087@binaire.cx> MIME-version: 1.0 X-Mailer: KMail [version 1.0.26] Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 8bit Excuse me the problem is from gcc posix_types.h conflicting with posix_types.h from linux posix_types.h -vhq From gcc-return-9393-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 00:46:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18440 invoked by alias); 24 Aug 1999 00:46:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18416 invoked from network); 24 Aug 1999 00:46:25 -0000 Received: from edison.dialix.com.au (root@203.12.2.8) by egcs.cygnus.com with SMTP; 24 Aug 1999 00:46:25 -0000 Received: from prophecy.com.au (www.prophecy.com.au [203.12.2.244]) by edison.dialix.com.au (8.9.1/8.9.1/DIALixFlat) with ESMTP id KAA14291; Tue, 24 Aug 1999 10:46:01 +1000 (EST) (envelope-from brendan@dgs.monash.edu.au) Received: from dhcp20.prophecy.com.au ([203.21.127.60] helo=dgs.monash.edu.au) by prophecy.com.au with esmtp (Exim 3.02 #1) id 11J4jy-00040l-00; Tue, 24 Aug 1999 10:47:06 +1000 Message-ID: <37C1EBA2.CEEBD997@dgs.monash.edu.au> Date: Tue, 24 Aug 1999 10:47:30 +1000 From: Brendan Simon Reply-To: brendan@dgs.monash.edu.au Organization: CTAM Pty Ltd X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 CC: gcc@gcc.gnu.org, ecos-discuss , Cross-GCC Subject: Re: [ECOS] Re: GCC: different OS targets. References: <37C099D3.C0BE0BC5@dgs.monash.edu.au> <37C1A9C5.ACE8F022@cygnus.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Larmour wrote: > Roger Williams wrote: > > > > >>>>> Brendan Simon writes: > > > > > I would like to be able to build gcc _ONCE_ for powerpc-eabi and > > > be able to build the RTEMS, eCos (or any other OS) libraries and > > > install them in an appropriate place. > > > > Yes indeed, this would be *very* helpful. I'm currently developing > > MPC8xx code for no-OS, Linux, and Neutrino, and I have separate > > development installations for each of these. I want to start working > > with eCos, but I dread the thought of yet another set of powerpc-eabi > > tools and libraries... > > You only need a standard powerpc-eabi toolchain for eCos, not a special one. > The only constraint is that it must be post egcs-1.1.2. gcc-2.95.1 should > work absolutely fine. > > As Bart Veer mentioned on ecos-discuss, things like thread-safe C++ > exceptions require knowledge of the OS. However, to be honest, I think > that's all there is. If you were not interested in thread-safe C++ > exceptions - and many RTOS folks aren't - then in general I don't think > there is any technical reason for different toolchain targets, apart from > convenience. I would be (I think). Surely this code would be part of gcc. If it is bleeding edge then the use of gcc snapshots or patches would work. > But this isn't just convenience for the OS developers, but also for the > compiler developers. If you consolidated two similar toolchains into one, > e.g. powerpc-eabi and powerpc-elf, then this suddenly means you have to > build (at least) twice the number of multi-libs when building a completely > generic set of tools, in order to support the two ABIs. If you look at the > current powerpc-eabi compiler, you'll see that it already has 25 multi-libs, > which means building versions of libgcc, newlib, libio, and libstdc++ 25 > times, which is already painful and disk-intensive. It would be nice to have just one compiler but I think I could live with having one compiler for each ABI, but having multiple compilers for the same ABI (eg EABI) seems wasteful. I would probably still push for the one compiler and be able to select the multilibs to build (specify each lib or family of libs via configure). > BTW, for these reasons, making eCos use the standard toolchain isn't as > clean as we would like. We override the linker script, and use -nostdlib to > avoid picking up the default crt0's and libc. I don't know how easy it is > for other OS's to do something similar though. Surely this is easily accomplised via the specs file (eg. -mecos). Brendan Simon. From gcc-return-9394-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 00:50:12 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20381 invoked by alias); 24 Aug 1999 00:50:09 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20358 invoked from network); 24 Aug 1999 00:50:08 -0000 Received: from goose.prod.itd.earthlink.net (207.217.120.18) by egcs.cygnus.com with SMTP; 24 Aug 1999 00:50:08 -0000 Received: from earthlink.net (sdn-ar-003varestP168.dialsprint.net [168.191.219.104]) by goose.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id RAA19686 for ; Mon, 23 Aug 1999 17:50:04 -0700 (PDT) Message-ID: <37C1EC14.42E9CD94@earthlink.net> Date: Mon, 23 Aug 1999 20:49:24 -0400 From: Linda Gricius Reply-To: lgricius@earthlink.net X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Installing compiler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm trying to install the gcc compiler on my Windows NT system. I downloaded the core compiler and the C++ distribution from your web site. When I unpack thee two files using bzip2 I get files that ends in _tar with no file extension. I've tried to run jar and winzip on the resulting *_tar files, but they don't work. How do I unpack the *_tar files under Windows NT. Also, will this C++ compiler run on Windows 95/98? Thanks! From gcc-return-9395-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 00:55:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22008 invoked by alias); 24 Aug 1999 00:55:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21993 invoked from network); 24 Aug 1999 00:55:09 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 24 Aug 1999 00:55:09 -0000 Received: from elmo.cygnus.com (elmo.cygnus.com [205.180.230.137]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA02379; Mon, 23 Aug 1999 17:55:08 -0700 (PDT) Received: (meissner@localhost) by elmo.cygnus.com (8.8.7/8.6.4) id RAA00725; Mon, 23 Aug 1999 17:55:08 -0700 Message-ID: <19990823205508.B698@elmo.cygnus.com> Date: Mon, 23 Aug 1999 20:55:08 -0400 From: Michael Meissner To: David Edelsohn , brendan@dgs.monash.edu.au Cc: egcs mailing list , Cross-GCC Subject: Re: GCC: different OS targets. References: <9908231553.AA33602@marc.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <9908231553.AA33602@marc.watson.ibm.com>; from David Edelsohn on Mon, Aug 23, 1999 at 11:53:48AM -0400 On Mon, Aug 23, 1999 at 11:53:48AM -0400, David Edelsohn wrote: > The PowerPC port of GCC can be configured for AIX or for SVR4. > The SVR4 port allows an AIX-style calling convention as compatibility for > a very old embedded PowerPC environment that Cygnus once produced. One > cannot build a single compiler for full support of both ABIs. Linux, > eABI, Solaris, and SysV are all SVR4 variants and can be selected with a > command-line option to a single compiler. Actually the -mcall-aix support is to be compatible with the calling sequence GCC used before I added the eABI support. I think Kenner was the original author. There are major Cygnus customers that still use it, so I would prefer it not be removed, sigh.... The -mcall-aixdesc switch, which is not documented, was my attempt to merge the two major ABIs into one compiler (this was before I added the now defunct NT support). When I moved to a faster computer (from a 90 Mhz Pentium to a dual 200 Mhz Pentium Pro) and my builds became much faster, I lost interest in trying to use one compiler to support all of the ABI's. -- Michael Meissner, Cygnus Solutions PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886 email: meissner@cygnus.com phone: 978-486-9304 fax: 978-692-4482 From gcc-return-9396-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 02:42:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32598 invoked by alias); 24 Aug 1999 02:42:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32582 invoked from network); 24 Aug 1999 02:42:35 -0000 Received: from mmpp5.iie.ncku.edu.tw (140.116.46.128) by egcs.cygnus.com with SMTP; 24 Aug 1999 02:42:35 -0000 Received: (qmail 4900 invoked by uid 502); 24 Aug 1999 02:36:18 -0000 Message-ID: <19990824023618.4899.qmail@mmpp5.iie.ncku.edu.tw> From: pschen@mmpp5.iie.ncku.edu.tw Subject: What different between PIC code and non-PIC code? To: gcc@gcc.gnu.org Date: Tue, 24 Aug 1999 10:36:18 +0800 (CST) Content-Type: text Hi: PIC is position independent code. If the program is PIC, then that program can be relocated at run-time. I dont compile a program using -fPIC option normally. The program also can be relocated at run-time. That is no different between using -fPIC and no-using. But I see the compiler output asemble-files between them, it is different. That is confused me. How to explain it? There is SYMBLE "_GLOBAL_OFFSET_TABLE" in the assemble-file from gcc by using -fPIC option. What is _GLOBAL_OFFSET_TABLE? Thanks your help, Thanks very much! Ps. Chen From gcc-return-9397-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 02:43:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 127 invoked by alias); 24 Aug 1999 02:43:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 85 invoked from network); 24 Aug 1999 02:43:16 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 24 Aug 1999 02:43:16 -0000 Received: (qmail 12848 invoked by alias); 24 Aug 1999 02:43:04 -0000 Received: (qmail 12833 invoked from network); 24 Aug 1999 02:43:02 -0000 Received: from peshwari.cygnus.co.uk (HELO cygnus.co.uk) (jlarmour@194.130.39.29) by dns.cygnus.co.uk with SMTP; 24 Aug 1999 02:43:02 -0000 Message-ID: <37C206B6.B9994187@cygnus.co.uk> Date: Tue, 24 Aug 1999 02:43:02 +0000 From: Jonathan Larmour Organization: Cygnus Solutions X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: brendan@dgs.monash.edu.au CC: gcc@gcc.gnu.org, ecos-discuss , Cross-GCC Subject: Re: [ECOS] Re: GCC: different OS targets. References: <37C099D3.C0BE0BC5@dgs.monash.edu.au> <37C1A9C5.ACE8F022@cygnus.co.uk> <37C1EBA2.CEEBD997@dgs.monash.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brendan Simon wrote: > > Jonathan Larmour wrote: > > [snip] > It would be nice to have just one compiler but I think I could live with having > one compiler for each ABI, but having multiple compilers for the same ABI (eg > EABI) seems wasteful. I would probably still push for the one compiler and be > able to select the multilibs to build (specify each lib or family of libs via > configure). But then you wouldn't have a single compiler - you would only have a single source base. You would need to recompile things everytime you needed a new multilib. Is this really that much better? Lazy compilation would be an interesting idea though - thus hammering home the benefits of Open Source :-). > > BTW, for these reasons, making eCos use the standard toolchain isn't as > > clean as we would like. We override the linker script, and use -nostdlib to > > avoid picking up the default crt0's and libc. I don't know how easy it is > > for other OS's to do something similar though. > > Surely this is easily accomplised via the specs file (eg. -mecos). Sure, if you are willing to encourage users to patch existing spec files :-). Alternatively, you just do what we do and encourage users to use Makefiles so they have less to type. That means you aren't forcing a user to tamper with an existing toolchain, which they may be using for non-eCos purposes as well. Jifl -- Cygnus Solutions, 35 Cambridge Place, Cambridge, UK. Tel: +44 (1223) 728762 "I used to have an open mind but || Get yer free open source RTOS's here... my brains kept falling out." || http://sourceware.cygnus.com/ecos Help fight spam! http://spam.abuse.net/ These opinions are all my own fault From gcc-return-9398-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 03:06:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6660 invoked by alias); 24 Aug 1999 03:06:29 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6621 invoked from network); 24 Aug 1999 03:06:24 -0000 Received: from unknown (HELO ntns1.sunplus.com.tw) (210.66.168.124) by egcs.cygnus.com with SMTP; 24 Aug 1999 03:06:24 -0000 Received: by ntns1.sunplus.com.tw(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 482567D7.000D5672 ; Tue, 24 Aug 1999 10:25:40 +0800 X-Lotus-FromDomain: SUNPLUS From: potatooo@sunplus.com.tw To: egcs@egcs.cygnus.com Message-ID: <482567D7.000D54F5.00@ntns1.sunplus.com.tw> Date: Tue, 24 Aug 1999 10:25:36 +0800 Subject: Re: egcs/Solaris status Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline > > > Jerffery A Law wrote: > > > 1) GCC does not bootstrap with Sun's fully patched C compiler 5.0. > > > This may be a problem with Sun's compiler, but I doubt it. > > > In fact 'make bootstrap' will usually fail whatever the compiler used > > > to bootstrap. See my messsage to this list: > > > GCC 2.95.1 'make bootstrap' oddities on Solaris > > Is this a comparison failure? If so, it is a bug in the Solaris 5.0 > > compilers. > No, this is not a comparison failure, but it could well be a bug in the > Solaris 5.0 compiler. I tried to build GCC with a fully patched Sun C > compiler once again. Here are the results: Months ago I've also run into the same problem (on solaris 2.5.1 systems with SunCC), finally I've tracked down the bug to the strlen() function provided by Solaris complier, which unrolled the strlen() by 4 and cause a SEGV exception around the end of a string. SOLUTION: provide a strlen() yourself or update your vendor compiler. potatooo. From gcc-return-9399-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 03:48:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10701 invoked by alias); 24 Aug 1999 03:48:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10686 invoked from network); 24 Aug 1999 03:48:23 -0000 Received: from postal.thewrittenword.com (china@208.150.51.101) by egcs.cygnus.com with SMTP; 24 Aug 1999 03:48:23 -0000 Received: (from china@localhost) by postal.thewrittenword.com (8.9.3/8.9.3) id WAA19294; Mon, 23 Aug 1999 22:44:07 -0500 (CDT) Date: Mon, 23 Aug 1999 22:44:06 -0500 From: egcs@thewrittenword.com To: Dimitri PAPADOPOULOS-ORFANOS Cc: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status Message-ID: <19990823224406.A21312@postal.thewrittenword.com> Reply-To: egcs@egcs.cygnus.com References: <199908231310.PAA06803@orcanie.shfj.cea.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199908231310.PAA06803@orcanie.shfj.cea.fr>; from Dimitri PAPADOPOULOS-ORFANOS on Mon, Aug 23, 1999 at 03:10:15PM +0200 On Mon, Aug 23, 1999 at 03:10:15PM +0200, Dimitri PAPADOPOULOS-ORFANOS wrote: > Jerffery A Law wrote: > > In message <37BEC99E.9BCE3572@club-internet.fr>you write: > > > 1) GCC does not bootstrap with Sun's fully patched C compiler 5.0. > > > This may be a problem with Sun's compiler, but I doubt it. > > > In fact 'make bootstrap' will usually fail whatever the compiler used > > > to bootstrap. See my messsage to this list: > > > GCC 2.95.1 'make bootstrap' oddities on Solaris > > Is this a comparison failure? If so, it is a bug in the Solaris 5.0 > compilers. > > No, this is not a comparison failure, but it could well be a bug in the > Solaris 5.0 compiler. I tried to build GCC with a fully patched Sun C > compiler once again. Here are the results: I have a fully patched Sun 5.0 C compiler and I do get a comparison failure. I get no seg fault during a build. I get the exact same results on 2.5.1, 2.6, and 2.7. I'm using Sun as/ld. I don't configure with shared library support or threads though. > Dimitri Papadopoulos -- albert chin (china@thewrittenword.com) From gcc-return-9400-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 04:15:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13806 invoked by alias); 24 Aug 1999 04:15:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13757 invoked from network); 24 Aug 1999 04:15:53 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 24 Aug 1999 04:15:53 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id VAA12222; Mon, 23 Aug 1999 21:15:43 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id VAA00092; Mon, 23 Aug 1999 21:15:42 -0700 (PDT) Date: Mon, 23 Aug 1999 21:15:42 -0700 (PDT) Message-Id: <199908240415.VAA00092@kankakee.wrs.com> To: gcc@gcc.gnu.org, pschen@mmpp5.iie.ncku.edu.tw Subject: Re: What different between PIC code and non-PIC code? > From: pschen@mmpp5.iie.ncku.edu.tw > Date: Tue, 24 Aug 1999 10:36:18 +0800 (CST) > PIC is position independent code. Yes. > If the program is PIC, then that program can be relocated > at run-time. This is imprecise, but yes. > I dont compile a program using -fPIC option normally. The > program also can be relocated at run-time. If by relocated, you mean moved without running relocs, then no, it cannot be. If by relocated, you mean moved, and running relocs, then yes. Most people use the first meaning. > That is no different between using -fPIC and no-using. Ok, maybe, depends upon what you mean. > But I see the compiler output asemble-files between them, it is > different. That is confused me. How to explain it? when org 0x100 jump A A: is turned into C3 01 03 jump 0x103 then we say that is not PIC code. When it is turned into 10 80 00 00 jump .+4 we say it is PIC code. The first code cannot be run at any address other than 100, the second can run at any address. The difference is that one is PC relative addressing mode (the later one). When you see code gen differences, it is to use PC relative addressing modes. That _is_ the difference. > There is SYMBLE "_GLOBAL_OFFSET_TABLE" in the assemble-file from > gcc by using -fPIC option. What is _GLOBAL_OFFSET_TABLE? I am sorry, this is way beyond the scope of this list. Please consult your OS documentation. Most people probably don't have the time to answer questions like this around here. From gcc-return-9401-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 04:19:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14894 invoked by alias); 24 Aug 1999 04:19:23 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14879 invoked from network); 24 Aug 1999 04:19:22 -0000 Received: from spectre.ktb.net (@198.175.228.43) by egcs.cygnus.com with SMTP; 24 Aug 1999 04:19:22 -0000 Received: from sid.boxsoft.com (root@pm01-06.ktb.net [208.34.160.16]) by spectre.ktb.net (8.9.3/KTBNET-4.0) with ESMTP id VAA24764; Mon, 23 Aug 1999 21:17:20 -0700 Received: from 3eye.boxsoft.com (patrick@3eye.boxsoft [192.168.69.3]) by sid.boxsoft.com (8.8.7/8.8.7) with ESMTP id VAA32465; Mon, 23 Aug 1999 21:23:20 -0700 Received: (from patrick@localhost) by 3eye.boxsoft.com (8.8.7/8.8.7) id VAA15832; Mon, 23 Aug 1999 21:25:08 -0700 From: patrick Message-Id: <199908240425.VAA15832@3eye.boxsoft.com> Subject: Re: scope issue To: dvv@dvv.org (Dima Volodin) Date: Mon, 23 Aug 1999 21:25:08 -0700 (PDT) Cc: gcc@gcc.gnu.org (gcc list (aka egcs)) In-Reply-To: <37C1B1E4.4FA8B09E@dvv.org> from "Dima Volodin" at Aug 23, 99 04:41:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit sometime in the late 1900s Dima replied to Richard: > Richard Harvey Chapman wrote: > > > Is there a correct output for the following? > > No, there isn't. i can understand your answer for the second printf() but not for the first one. i think the first one should always give 9 (in this case). what am i missing? > > int main ( void ) > > { > > int x=9; > > > > printf ("%d\n", (x + x++) - --x); > > printf ("%d %d\n", ++x, x++); > > } > > > > I believe that it should be: > > 9 > > 10 10 > > > > but different compilers have given different answers. > > > > R. > > Dima patrick at boxsoft dot com sidster at drink dot com -- The rain it raineth on the just And also on the unjust fella, But chiefly on the just, because The unjust steals the just's umbrella. From gcc-return-9402-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 05:31:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21662 invoked by alias); 24 Aug 1999 05:31: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21627 invoked from network); 24 Aug 1999 05:31:23 -0000 Received: from burka.rdy.com (root@205.149.163.30) by egcs.cygnus.com with SMTP; 24 Aug 1999 05:31:23 -0000 Received: from localhost (root@localhost.rdy.com [127.0.0.1]) by burka.rdy.com (8.9.3/RDY&DVV) with SMTP id WAA27195; Mon, 23 Aug 1999 22:31:15 -0700 (PDT) From: dvv@dvv.ru (Dima Volodin) To: patrick Cc: gcc@gcc.gnu.org Subject: Re: scope issue Date: Tue, 24 Aug 1999 05:31:14 GMT Organization: Huh? Message-ID: <37c42baa.21955870@localhost> References: <199908240425.VAA15832@3eye.boxsoft.com> In-Reply-To: <199908240425.VAA15832@3eye.boxsoft.com> X-Mailer: Bad Mojo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Mon, 23 Aug 1999 21:25:08 -0700 (PDT), you wrote: > >sometime in the late 1900s Dima replied to Richard: > >> Richard Harvey Chapman wrote: >> >> > Is there a correct output for the following? >> >> No, there isn't. > > >i can understand your answer for the second printf() but not >for the first one. > >i think the first one should always give 9 (in this case). > >what am i missing? Reading section 6.3 of the Standard (and footnote 34 thereof). In the c9x draft, it's section 6.5 and footnote 60. >patrick at boxsoft dot com >sidster at drink dot com Dima From gcc-return-9403-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 05:41:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25732 invoked by alias); 24 Aug 1999 05:41:36 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25705 invoked from network); 24 Aug 1999 05:41:35 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 24 Aug 1999 05:41:35 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id WAA00508 for ; Mon, 23 Aug 1999 22:35:26 -0700 Message-Id: <199908240535.WAA00508@zack.bitmover.com> To: gcc@gcc.gnu.org Subject: init_mov_optab obsolete? Date: Mon, 23 Aug 1999 22:35:26 -0700 From: Zack Weinberg If EXTRA_CC_MODES is defined, genemit.c writes out a special function called init_mov_optab that adds entries to mov_optab for patterns that move those modes around. However, it appears to me that init_all_optabs (generated by genopinit.c) will set up those entries anyway. Am I right, and if so, can we kill it? It's not doing any harm, but it is confusing when you're trying to unravel what the md processors do. (N.B. No current machine description actually defines patterns to move extra cc modes around.) zw From gcc-return-9404-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 06:32:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 286 invoked by alias); 24 Aug 1999 06:32:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 270 invoked from network); 24 Aug 1999 06:32:01 -0000 Received: from host162.nashville.com (HELO rjlhome.sco.com) (207.65.231.162) by egcs.cygnus.com with SMTP; 24 Aug 1999 06:32:01 -0000 Received: (from robertl@localhost) by rjlhome.sco.com (8.8.8/SCO5) id BAA01239; Tue, 24 Aug 1999 01:30:50 -0500 (CDT) Date: Tue, 24 Aug 1999 01:30:50 -0500 From: Robert Lipe To: patrick Cc: Dima Volodin , "gcc list (aka egcs)" Subject: Re: scope issue Message-ID: <19990824013050.A742@rjlhome.sco.com> References: <37C1B1E4.4FA8B09E@dvv.org> <199908240425.VAA15832@3eye.boxsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95us In-Reply-To: <199908240425.VAA15832@3eye.boxsoft.com>; from patrick on Mon, Aug 23, 1999 at 09:25:08PM -0700 > > > printf ("%d\n", (x + x++) - --x); > what am i missing? A book on C programming. AFAIR, this is covered in the "C Pitfalls and Traps" as well as the FAQ in the comp.lang.c. Search for "Sequence points" in your travels. (I think this is even the very example given....) These lists are for compiler development issues. Please don't use them to learn C. From gcc-return-9405-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 06:38:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2133 invoked by alias); 24 Aug 1999 06:38:35 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2108 invoked from network); 24 Aug 1999 06:38:30 -0000 Received: from unknown (HELO upchuck.cygnus.com) (root@208.224.120.150) by egcs.cygnus.com with SMTP; 24 Aug 1999 06:38:30 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id AAA14908; Tue, 24 Aug 1999 00:37:34 -0600 X-Mailer: exmh version 2.0.2 To: Zack Weinberg cc: gcc@gcc.gnu.org Subject: Re: RTL type checking and '0' format codes Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 16 Aug 1999 16:10:42 PDT. <199908162310.QAA09148@zack.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Aug 1999 00:37:34 -0600 Message-ID: <14905.935476654@upchuck.cygnus.com> From: Jeffrey A Law In message <199908162310.QAA09148@zack.bitmover.com>you write: > > I have been looking into implementing type checking for RTL, much like > the type checking for trees we already have. The various XFOO > macros would check the slot against the format, and abort if it was > invalid. Excellent! We actually had someone working on this earlier, but we could never get a copyright assignment for the work, so it never got integrated. > '0' format codes cause problems. '0' is documented to mean that the > slot is only valid in a specific pass, and should be ignored > otherwise. They aren't initialized in gen_rtx_FOO, and they're > ignored in generic copy-or-examine-RTL code. Right. > Most '0' slots are always addressed with a specific type, but the > information on their type isn't in the format. LABEL_NUSES, > JUMP_LABEL, LABEL_REFS, LABEL_NEXTREF, and CONTAINING_INSN are like > this. We would like to type check them. I'd punt initially and get the basic checking code installed. Then return to this issue. jeff From gcc-return-9406-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 06:51:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5851 invoked by alias); 24 Aug 1999 06:51:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5836 invoked from network); 24 Aug 1999 06:51:25 -0000 Received: from thoth.mch.sni.de (192.35.17.2) by egcs.cygnus.com with SMTP; 24 Aug 1999 06:51:25 -0000 X-Envelope-Sender-Is: martin.kahlert@mchp.siemens.de (at relayer thoth.mch.sni.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.14]) by thoth.mch.sni.de (8.9.3/8.9.3) with ESMTP id IAA00712 for ; Tue, 24 Aug 1999 08:51:19 +0200 (MET DST) Received: from keksy.mchp.siemens.de (keksy.mchp.siemens.de [139.23.187.70]) by mail2.siemens.de (8.9.3/8.9.3) with ESMTP id IAA24148 for ; Tue, 24 Aug 1999 08:51:19 +0200 (MET DST) Received: (from kahlert@localhost) by keksy.mchp.siemens.de (8.9.3/8.9.3) id IAA07191 for egcs@egcs.cygnus.com; Tue, 24 Aug 1999 08:51:18 +0200 Date: Tue, 24 Aug 1999 08:51:18 +0200 From: Martin Kahlert Message-Id: <199908240651.IAA07191@keksy.mchp.siemens.de> To: egcs@egcs.cygnus.com Subject: snapshots? Hi! When will the snapshot mechanism be enabled again? I don't have CVS access. Thanks, Martin. From gcc-return-9407-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 07:02:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8469 invoked by alias); 24 Aug 1999 07:02:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8433 invoked from network); 24 Aug 1999 07:02:10 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 24 Aug 1999 07:02:10 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id XAA03486; Mon, 23 Aug 1999 23:56:00 -0700 Message-Id: <199908240656.XAA03486@zack.bitmover.com> To: law@cygnus.com cc: gcc@gcc.gnu.org Subject: Re: RTL type checking and '0' format codes In-Reply-To: Your message of "Tue, 24 Aug 1999 00:37:34 MDT." <14905.935476654@upchuck.cygnus.com> Date: Mon, 23 Aug 1999 23:55:59 -0700 From: Zack Weinberg Jeffrey A Law wrote: > In message <199908162310.QAA09148@zack.bitmover.com>you write: > > > > I have been looking into implementing type checking for RTL, much like > > the type checking for trees we already have. [...] > > Most '0' slots are always addressed with a specific type, but the > > information on their type isn't in the format. LABEL_NUSES, > > JUMP_LABEL, LABEL_REFS, LABEL_NEXTREF, and CONTAINING_INSN are like > > this. We would like to type check them. > I'd punt initially and get the basic checking code installed. Then return > to this issue. Agree, and I'm actually testing a patch that does this even as we speak. It has knock-on effects all over the code and my patch backlog is getting quite large, so I won't be able to submit it for awhile. zw From gcc-return-9408-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 09:36:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28305 invoked by alias); 24 Aug 1999 09:35:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28290 invoked from network); 24 Aug 1999 09:35:48 -0000 Received: from dire.bris.ac.uk (137.222.10.60) by egcs.cygnus.com with SMTP; 24 Aug 1999 09:35:48 -0000 Received: from cs.bris.ac.uk (actually host luna.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 24 Aug 1999 10:35:40 +0100 Received: from acm.org (manao [137.222.102.67]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id KAA21937; Tue, 24 Aug 1999 10:34:48 +0100 (BST) Message-ID: <37C26737.9317F0DF@acm.org> Date: Tue, 24 Aug 1999 10:34:47 +0100 From: Nathan Sidwell Reply-To: nathan@compsci.bristol.ac.uk Organization: University of Bristol X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Richard Harvey Chapman CC: gcc@gcc.gnu.org Subject: Re: scope issue References: <4.2.0.58.19990823132909.00a5e220@kms> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Richard Harvey Chapman wrote: > > Is there a correct output for the following? Richard, we're going to jump on you from a great height, there is no meaning to this code. Learn what undefined effects mean, learn what a sequence point is. Go read the C FAQ. What's this got to do with scope anyway? nathan -- Dr Nathan Sidwell :: Computer Science Department :: Bristol University I have seen the death of PhotoShop -- it is called GIMP nathan@acm.org http://www.cs.bris.ac.uk/~nathan/ nathan@cs.bris.ac.uk From gcc-return-9409-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 10:23:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7286 invoked by alias); 24 Aug 1999 10:23:15 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7265 invoked by uid 220); 24 Aug 1999 10:23:05 -0000 Date: 24 Aug 1999 10:23:05 -0000 Message-ID: <19990824102305.7261.qmail@egcs.cygnus.com> From: law@egcs.cygnus.com To: egcs@egcs.cygnus.com Subject: egcs-ss-19990824 is now available egcs-ss-19990824 is now available on egcs.cygnus.com:/pub/egcs/snapshots/1999-08-24 (and on various mirrors, see the egcs home page for mirror sites). You'll find: egcs-19990824.tar.gz The full egcs snapshot, including all languages runtime libraries. egcs-core-19990824.tar.gz Just the C front end and core compiler. egcs-g++-19990824.tar.gz The g++ language and runtime. egcs-g77-19990824.tar.gz The g77 language and runtime. egcs-objc-19990824.tar.gz The Objective-C font end and runtime. egcs-java-19990824.tar.gz The Java font end. egcs-chill-19990824.tar.gz The Chill font end and runtime. Diffs from 19990808 are not available. Note at times you may find newer directories on the server with limited permissions. These represent snapshots that have not yet been verified as correct, or are known to be incorrect. When a particular snapshot is ready for public consumption the directory permissions are relaxed, the LATEST-IS- file is updated and a message is sent to the egcs list. Using a snapshot before it's officially made available is an unwise thing to do since it may become impossible to update to an official snapshot. The "egcs_latest_snapshot" tag has been moved. You can use cvs update -regcs_latest_snapshot to update your CVS tree to the latest official snapshot. From gcc-return-9410-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 13:14:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20127 invoked by alias); 24 Aug 1999 13:14:09 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20103 invoked from network); 24 Aug 1999 13:13:50 -0000 Received: from unknown (HELO mail.prefres.com) (209.96.23.220) by egcs.cygnus.com with SMTP; 24 Aug 1999 13:13:50 -0000 Received: by mail.prefres.com from localhost (router,SLMail V3.2); Tue, 24 Aug 1999 08:15:50 -0500 Received: from draco [209.96.23.216] by mail.prefres.com [209.96.23.220] (SLmail 3.2.3113) with ESMTP id 4E8C3EB7502C11D3B7100080C813F968 for ; Tue, 24 Aug 1999 08:15:50 -0500 Message-Id: <4.2.0.58.19990824080738.00ca26f0@209.96.23.220> X-Sender: mminnis@209.96.23.220 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 24 Aug 1999 08:07:51 -0500 To: gcc@gcc.gnu.org From: "Matt Minnis" Subject: Dwarf/Elf debugging in GCC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SLUIDL: AD7BAF9D-5A1B11D3-B7100080-C813F968 Jason, I am looking into making GCC for the Motorola Coldfire (M68K) output Elf files for various commercial debugging manufacturers. What is required to do this? What is the machine specific stuff that I have to look at to change? I am new to GCC internals so forgive my ignorance. Thanks, Matt Minnis ========================================================= Preferred Resources (314) 567-7600 phone 701 Emerson rd. (314) 993-6699 fax Suite 475 St. Louis, MO 63141 ========================================================= From gcc-return-9411-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 14:08:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28067 invoked by alias); 24 Aug 1999 14:08:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28045 invoked from network); 24 Aug 1999 14:08:53 -0000 Received: from atlas.lure.u-psud.fr (193.55.24.209) by egcs.cygnus.com with SMTP; 24 Aug 1999 14:08:53 -0000 Received: from lure.u-psud.fr ([192.168.79.67]) by ariane.lure.u-psud.fr (MX V4.1 VAX) with SMTP; Tue, 24 Aug 1999 16:08:49 MET DST Message-ID: <37C2A770.C55551C6@lure.u-psud.fr> Date: Tue, 24 Aug 1999 16:08:49 +0200 From: Gerard Flynn Organization: LURE/CNRS X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Using g77 and gdb together Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am having many problems in trying to use gdb to debug a very large fortran program compiled with g77. In particular gdb seems to be confused about source line numbers. For exemple there exists a subroutine called amorti_ (AMORTI) in a given source file. The line number of the subroutine statement is 498 and the first executable statement is an IF at line 528 followed by an assignment at 529. Now if in gdb I type: > break amorti_ I see: Breakpoint 2 at 0x80c65be: file ../beta/source/emequi.f, line 648. Line 648 is the RETURN statement at the end of the routine. If I type > list amorti_ gdb lists lines between 582 and 591, somewhere in the middle of the routine. The source file in question makes use of many INCLUDE statements some of which are nested. The include files, source files and executable are all in separate directories. It also contains routines containing ENTRY statements (although the particular routine I mentioned here does not.). Initial attempts to reproduce this behavior with a small test program have failed. Does anyone have any idea what is going on here ? I'm using gdb 4.18 and gcc 2.95.1 but I believe that this type of behavior existed in previous versions. Thanks in advance for any help, Gerard Flynn From gcc-return-9412-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 14:10:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28910 invoked by alias); 24 Aug 1999 14:10:40 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28895 invoked from network); 24 Aug 1999 14:10:38 -0000 Received: from gatekeeper.acxiom.com (206.31.111.18) by egcs.cygnus.com with SMTP; 24 Aug 1999 14:10:38 -0000 Received: from gatekeeper.acxiom.com (root@localhost) by gatekeeper.acxiom.com with ESMTP id JAA29484 for ; Tue, 24 Aug 1999 09:06:55 -0500 (CDT) Received: from popmail.conway.acxiom.com ([204.107.111.23]) by gatekeeper.acxiom.com with SMTP id JAA29476 for ; Tue, 24 Aug 1999 09:06:53 -0500 (CDT) Received: by popmail.conway.acxiom.com from localhost (router,SLMail V3.2); Tue, 24 Aug 1999 09:14:18 -0500 Received: by popmail.conway.acxiom.com from popmail.conway.acxiom.com (204.107.111.23::mail daemon; unverified,SLMail V3.2); Tue, 24 Aug 1999 09:14:18 -0500 Received: FROM po-conway-con1.conway.acxiom.com BY popmail.conway.acxiom.com ; Tue Aug 24 09:14:14 1999 -0500 Received: by exchange.conway.acxiom.com with Internet Mail Service (5.5.2650.10) id ; Tue, 24 Aug 1999 09:14:18 -0500 Message-ID: <8174DD8D2470D211BAAA0000F81E7A5302F6EBEF@po_conway_2.conway.acxiom.com> From: bgreen - Bryan Green To: "'lgricius@earthlink.net'" , gcc@gcc.gnu.org Subject: RE: Installing compiler Date: Tue, 24 Aug 1999 09:14:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" X-SLUIDL: 2668F5D5-5A1F11D3-98850000-F6775E9A After you use bzip2 to unpack the files, you have to rename them. replace the underscore before tar with a '.'. Then use winzip. -----Original Message----- From: Linda Gricius [mailto:lgricius@earthlink.net] Sent: Monday, August 23, 1999 7:49 PM To: gcc@gcc.gnu.org Subject: Installing compiler I'm trying to install the gcc compiler on my Windows NT system. I downloaded the core compiler and the C++ distribution from your web site. When I unpack thee two files using bzip2 I get files that ends in _tar with no file extension. I've tried to run jar and winzip on the resulting *_tar files, but they don't work. How do I unpack the *_tar files under Windows NT. Also, will this C++ compiler run on Windows 95/98? Thanks! From gcc-return-9413-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 14:15:17 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29847 invoked by alias); 24 Aug 1999 14:15:15 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29831 invoked from network); 24 Aug 1999 14:15:08 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 24 Aug 1999 14:15:08 -0000 Received: (qmail 26123 invoked by alias); 24 Aug 1999 14:15:06 -0000 Received: (qmail 26106 invoked from network); 24 Aug 1999 14:15:05 -0000 Received: from biriani.cygnus.co.uk (bernds@194.130.39.16) by dns.cygnus.co.uk with SMTP; 24 Aug 1999 14:15:05 -0000 Received: from localhost by biriani.cygnus.co.uk (UUNET PIPEX simple 1.30) id PAA25804; Tue, 24 Aug 1999 15:14:58 +0100 Date: Tue, 24 Aug 1999 15:14:57 +0100 (BST) From: Bernd Schmidt To: Franz Sirl cc: Joern Rennecke , dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com, kenner@vlsi1.ultra.nyu.edu Subject: Re: Deadly optimization bug (all gcc versions!) In-Reply-To: <99081823080500.00740@ns1102.munich.netsurf.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > Well, this is the analysis, however I have no idea how to fix it correctly :-(. > A local fix in if_then_else_cond() would be to compare the results of > nonzero_bits(x), reg_nonzero_bits[REGNO(x)] and > reg_last_set_nonzero_bits[REGNO(x)] and use the biggest one? But this may > just hide other potential problems with get_last_value()? I believe the code we need to fix is in get_last_value. The situation is this (target i686-linux with gcc-2.95): insn 11 : set (reg 24) [some value] insn 13 [i1]: set (reg 25) [some value] insn 16 : set (reg 24) (plus (reg 24) (const_int 1)) insn 18 [i2]: set (reg 27) (lshiftrt (reg 24) (const_int 1)) insn 20 [i3]: set (reg 26) (plus (reg 27) (reg 25)) We already substituted i2 into i3 and got a (valid) newpat that contains reg 24. Then, we try to substitute i1 into the newpat. subst_low_cuid gets set to INSN_CUID (i1). reg_last_set[24] is insn 16 at this point. The problem is that get_last_value returns the SET_SRC of insn 11, completely ignoring insn 16. The patch below seems to fix it. The whole block of code looks very suspicious, though. I'm under the impression it can't ever find a valid set. If it finds an insn before subst_low_cuid, shouldn't that one be pointed to by reg_last_set[regno]? I've tried completely disabling the whole if statement, and FWIW the optimization does not trigger once when compiling cc1. If no one can show that it can have an effect, I suggest ripping it out. The block of code was introduced by Richard Kenner on Aug 2, 1992 (it's in gcc-2.2.2-2.3.1.diff.gz). Bernd * combine.c (get_last_value): Don't look for earlier sets if the last known set is somewhere in between the insns being combined. Index: combine.c =================================================================== RCS file: /egcs/carton/cvsfiles/egcs/gcc/combine.c,v retrieving revision 1.68 diff -u -p -r1.68 combine.c --- combine.c 1999/08/20 23:05:06 1.68 +++ combine.c 1999/08/24 13:59:03 @@ -10817,6 +10817,11 @@ get_last_value (x) { rtx insn, set; + /* We can't do anything if the value is set in between the insns we are + processing. */ + if (INSN_CUID (reg_last_set[regno]) <= INSN_CUID (subst_insn)) + return 0; + /* We can not do anything useful in this case, because there is an instruction which is not on the insn chain. */ if (subst_prev_insn) From gcc-return-9414-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 14:18:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30830 invoked by alias); 24 Aug 1999 14:18:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30814 invoked from network); 24 Aug 1999 14:18:45 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 24 Aug 1999 14:18:45 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA14780; Tue, 24 Aug 1999 07:18:43 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id HAA01576; Tue, 24 Aug 1999 07:18:42 -0700 (PDT) Date: Tue, 24 Aug 1999 07:18:42 -0700 (PDT) Message-Id: <199908241418.HAA01576@kankakee.wrs.com> To: gcc@gcc.gnu.org, mminnis@prefres.com Subject: Re: Dwarf/Elf debugging in GCC > Date: Tue, 24 Aug 1999 08:07:51 -0500 > To: gcc@gcc.gnu.org > From: "Matt Minnis" > I am looking into making GCC for the Motorola Coldfire (M68K) output > Elf files for various commercial debugging manufacturers. > What is required to do this? The ability to read source and understand things like (from gcc/configure.in): m68020-*-elf* | m68k-*-elf*) tm_file="m68k/m68020-elf.h" xm_file=m68k/xm-m68kv.h tmake_file=m68k/t-m68kelf header_files=math-68881.h ;; and know this means you must type configure --target=m68k-unknown-elf && make && make install? > What is the machine specific stuff that I have to look at to change? Do you have to change something? Is there something wrong with the above? See gcc/config/m68k/* for files you might want to change. Or maybe I just don't understand what you have/want. From gcc-return-9415-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 14:47:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2401 invoked by alias); 24 Aug 1999 14:47:06 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2323 invoked from network); 24 Aug 1999 14:46:56 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 24 Aug 1999 14:46:56 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id KAA29198 for ; Tue, 24 Aug 1999 10:46:53 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (root@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id KAA23939 for ; Tue, 24 Aug 1999 10:45:02 -0400 (EDT) Received: (qmail 22175 invoked by uid 500); 24 Aug 1999 14:40:05 -0000 Date: 24 Aug 1999 14:40:05 -0000 Message-ID: <19990824144005.22174.qmail@deer> To: flynn@lure.u-psud.fr CC: gcc@gcc.gnu.org cc: craig@jcb-sc.com In-reply-to: <37C2A770.C55551C6@lure.u-psud.fr> (message from Gerard Flynn on Tue, 24 Aug 1999 16:08:49 +0200) Subject: Re: Using g77 and gdb together References: <37C2A770.C55551C6@lure.u-psud.fr> >In particular gdb seems to be confused about source line numbers. For >exemple there exists a subroutine called amorti_ (AMORTI) in a given >source >file. The line number of the subroutine statement is 498 and the first >executable statement is an IF at line 528 followed by an assignment at >529. > >Now if in gdb I type: >> break amorti_ >I see: >Breakpoint 2 at 0x80c65be: file ../beta/source/emequi.f, line 648. > >Line 648 is the RETURN statement at the end of the routine. > >If I type >> list amorti_ > >gdb lists lines between 582 and 591, somewhere in the middle of the >routine. > >The source file in question makes use of many INCLUDE statements some of >which are nested. The include files, source files >and executable are all in separate directories. It also contains >routines containing >ENTRY statements (although the particular routine I mentioned here does >not.). Hmm. Many possible problems here. First, make sure you compile with `-g -O0' to turn off optimization, at least until you verify that this produces some reasonable gdb-time behavior. Now, there are several known problems with g77+gdb, some of which are not perhaps well-understood: - I think GCC 2.95 (thence g77 0.5.25) still has the "skidding break" bug I reported a couple of months back. The symptom of this bug is that when you break on a procedure (C "function") by name, rather than stop *before* the first executable statement, sometimes the debugger stops after it (i.e. before the second one). IIRC, this is not a gdb bug, and it was discussed and suggested was due to recent changes in flow.c. It's pretty easy to reproduce with a small test case. - g77 does have some problems (I think documented at least somewhat in the known-bugs section of the manual) tracking source line numbers across #include, INCLUDE, or both. It's probably the case that my view regarding this problem has been limited to its effect on diagnostics, and that it also affects line-number info provided for debuggers to track. I'm pretty sure the problem (which I think I "scoped out" some two years ago!) is entirely g77-specific. If you study the output of using `-g -S' when compiling pertinent code, you might learn ways to fix some of the above problems sufficiently to at least demonstrate whether your problems are entirely due to one or both of the above, versus some other problems. tq vm, (burley) From gcc-return-9416-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 14:54:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3908 invoked by alias); 24 Aug 1999 14:54:37 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3886 invoked from network); 24 Aug 1999 14:54:29 -0000 Received: from mumrik.nada.kth.se (130.237.226.10) by egcs.cygnus.com with SMTP; 24 Aug 1999 14:54:29 -0000 Received: from localhost (d92-foh@localhost) by mumrik.nada.kth.se (8.8.7/8.8.7) with SMTP id QAA21795 for ; Tue, 24 Aug 1999 16:54:13 +0200 (MET DST) Date: Tue, 24 Aug 1999 16:54:12 +0200 (MET DST) From: =?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?= To: gcc@gcc.gnu.org Subject: Strange behaviour in C++... In-Reply-To: <37C2A770.C55551C6@lure.u-psud.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The code below compiled with 2.95.1 (19990816) (on a RedHat 5.2 system i386) produces: Alfa 1=42 Alfa 2=42 BetaAlfa=42 Alfa 1=47 Alfa 2=134580865 GammaAlfa=47 AlfaGammaAlfa=47 Shouldn't Alfa 2 be 47 in the second creation? Cheers Fredrik --------------------------------------------------------- #include struct Alfa { virtual int alfa() = 0; }; struct Beta {}; struct Gamma {}; struct Alfa_i : public virtual Alfa { int a; Alfa_i (int aa) : a (aa) { } int alfa () { return a; } }; struct Beta_i : public virtual Beta, public Alfa_i { Beta_i (int bb) : Alfa_i (bb) { cerr << "Alfa 1=" << alfa ()<< endl; Alfa *a = this; cerr << "Alfa 2=" << a->alfa ()<< endl; } }; struct Gamma_i : public virtual Gamma, public Beta_i { Gamma_i (int cc) : Beta_i (cc) {} }; int main () { Beta_i *b = new Beta_i (42); cerr << "BetaAlfa=" << b->alfa() << endl; Gamma_i *g = new Gamma_i (47); cerr << "GammaAlfa=" << g->alfa() << endl; Alfa *a = g; cerr << "AlfaGammaAlfa=" << a->alfa() << endl; } From gcc-return-9417-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 15:55:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15848 invoked by alias); 24 Aug 1999 15:55:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15823 invoked from network); 24 Aug 1999 15:55:16 -0000 Received: from smtp.interlog.com (root@207.34.202.37) by egcs.cygnus.com with SMTP; 24 Aug 1999 15:55:16 -0000 Received: from crjnt2 (cj.interlog.com [199.212.157.174]) by smtp.interlog.com (8.9.1/8.9.1) with SMTP id LAA07123; Tue, 24 Aug 1999 11:55:03 -0400 (EDT) Message-Id: <3.0.32.19990824115643.009815f0@mail.interlog.com> X-Sender: cj@mail.interlog.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 24 Aug 1999 11:56:45 -0400 To: Fredrik =?iso-8859-1?Q?=D6hrstr=F6m?= , gcc@gcc.gnu.org From: "Christopher R. Jones" Subject: Re: Strange behaviour in C++... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Using Borland 5.0 on WinNT: Alfa 1=42 Alfa 2=42 BetaAlfa=42 Alfa 1=47 Alfa 2=47 GammaAlfa=47 AlfaGammaAlfa=47 > >The code below compiled with 2.95.1 (19990816) >(on a RedHat 5.2 system i386) produces: > >Alfa 1=42 >Alfa 2=42 >BetaAlfa=42 >Alfa 1=47 >Alfa 2=134580865 >GammaAlfa=47 >AlfaGammaAlfa=47 > >Shouldn't Alfa 2 be 47 in the second creation? > >Cheers >Fredrik > >--------------------------------------------------------- > > >#include > >struct Alfa >{ > virtual int alfa() = 0; >}; > >struct Beta >{}; > >struct Gamma >{}; > >struct Alfa_i : public virtual Alfa >{ > int a; > > Alfa_i (int aa) : a (aa) > { > } > > int alfa () > { > return a; > } >}; > >struct Beta_i : public virtual Beta, > public Alfa_i >{ > Beta_i (int bb) : Alfa_i (bb) > { > cerr << "Alfa 1=" << alfa ()<< endl; > Alfa *a = this; > cerr << "Alfa 2=" << a->alfa ()<< endl; > } >}; > >struct Gamma_i : public virtual Gamma, > public Beta_i >{ > Gamma_i (int cc) > : Beta_i (cc) > {} >}; > > >int main () >{ > Beta_i *b = new Beta_i (42); > cerr << "BetaAlfa=" << b->alfa() << endl; > > Gamma_i *g = new Gamma_i (47); > cerr << "GammaAlfa=" << g->alfa() << endl; > > Alfa *a = g; > cerr << "AlfaGammaAlfa=" << a->alfa() << endl; >} > > > > > Christopher R. Jones, P.Eng. 14 Oneida Avenue Toronto, Ontario M5J 2E3 Tel. 416 203-7465 Fax. 416 203-3044 Email cj@interlog.com From gcc-return-9418-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 16:37:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23135 invoked by alias); 24 Aug 1999 16:37:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23120 invoked from network); 24 Aug 1999 16:37:47 -0000 Received: from smtprtp1.ntcom.nortel.net (137.118.22.14) by egcs.cygnus.com with SMTP; 24 Aug 1999 16:37:47 -0000 Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprtp1.ntcom.nortel.net; Tue, 24 Aug 1999 12:37:18 -0400 Received: from zmtlde5a.ca.nortel.com ([47.64.13.90]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id RF0Q22J3; Tue, 24 Aug 1999 12:37:17 -0400 Received: from wmtl249c.nortel.ca (wmtl249c.ca.nortel.com [47.64.3.156]) by zmtlde5a.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Q064RMPR; Tue, 24 Aug 1999 12:37:17 -0400 From: "Jerry Quinn" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14274.51772.215325.181063@gargle.gargle.HOWL> Date: Tue, 24 Aug 1999 12:37:16 -0400 (EDT) To: "Christopher R. Jones" Cc: Fredrik =?iso-8859-1?Q?=D6hrstr=F6m?= , gcc@gcc.gnu.org Subject: Re: Strange behaviour in C++... In-Reply-To: <3.0.32.19990824115643.009815f0@mail.interlog.com> References: <3.0.32.19990824115643.009815f0@mail.interlog.com> X-Mailer: VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) gcc 2.95 on HPUX 10.20 also gives correct output. > Using Borland 5.0 on WinNT: > Alfa 1=42 > Alfa 2=42 > BetaAlfa=42 > Alfa 1=47 > Alfa 2=47 > GammaAlfa=47 > AlfaGammaAlfa=47 > > > > >The code below compiled with 2.95.1 (19990816) > >(on a RedHat 5.2 system i386) produces: > > > >Alfa 1=42 > >Alfa 2=42 > >BetaAlfa=42 > >Alfa 1=47 > >Alfa 2=134580865 > >GammaAlfa=47 > >AlfaGammaAlfa=47 > > > >Shouldn't Alfa 2 be 47 in the second creation? > > > >Cheers > >Fredrik -- Jerry Quinn Tel: (514) 761-8737 jquinn@nortelnetworks.com Fax: (514) 761-8505 Speech Recognition Research From gcc-return-9419-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 16:46:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26172 invoked by alias); 24 Aug 1999 16:46:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26156 invoked from network); 24 Aug 1999 16:46:26 -0000 Received: from ftp.lokigames.com (HELO mail.lokigames.com) (209.223.115.151) by egcs.cygnus.com with SMTP; 24 Aug 1999 16:46:26 -0000 Received: from namaste.lokigames-lan.com (router [209.223.115.150]) by mail.lokigames.com (8.9.3/8.9.3) with ESMTP id JAA28071 for ; Tue, 24 Aug 1999 09:53:14 -0700 Received: (from michael@localhost) by namaste.lokigames-lan.com (8.9.3/8.9.3) id JAA32438 for gcc@gcc.gnu.org; Tue, 24 Aug 1999 09:49:37 -0700 Date: Tue, 24 Aug 1999 09:49:37 -0700 From: Michael Vance To: gcc@gcc.gnu.org Subject: Anonymous structures in gcc-2.95.1 ? Message-ID: <19990824094937.G31192@namaste.lokigames-lan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us X-Operating-System: Linux 2.2.10 X-Uptime: 5:04pm up 17 days, 2:04, 5 users, load average: 2.05, 2.04, 2.00 I browsed the archives for information whether support for anonymous structures had been added to 2.95, but was only able to find posts that vaguely referred to code being added, dated sometime in July. That being the case, some VC code I'm porting fails to compile: class r_c { union { unsigned k; struct { unsigned a :1; unsigned r :31; }; }; bool il; protected: virtual ~r_c () {}; public: r_c (); }; int main( int argc, char* argv[] ) { return 0; } [michael@namaste util]$ make dummy.o g++ dummy.cpp -c -Wall -I/usr/X11R6/include -I../loki `glib-config --cflags` -I../render -I../util dummy.cpp:8: anonymous class type not used to declare any objects make: *** [dummy.o] Error 1 [michael@namaste util]$ Is support for anonymous structs not in place, and if not, should I expect it anytime soon? I have a patch against egcs-1.1.1 that implements it (very small), but it doesn't apply cleanly anymore. Any info appreciated, m. -- "How wonderful! How mysterious Programmer I carry wood! I draw water!" Loki Entertainment Software - Anonymous Tao poet From gcc-return-9420-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 17:15:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28914 invoked by alias); 24 Aug 1999 17:15:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28887 invoked from network); 24 Aug 1999 17:15:00 -0000 Received: from alecto.physics.uiuc.edu (130.126.8.20) by egcs.cygnus.com with SMTP; 24 Aug 1999 17:15:00 -0000 Received: from localhost (menscher@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) with SMTP id MAA17483 for ; Tue, 24 Aug 1999 12:14:55 -0500 (CDT) X-Authentication-Warning: alecto.physics.uiuc.edu: menscher owned process doing -bs Date: Tue, 24 Aug 1999 12:14:55 -0500 (CDT) From: Damian Menscher X-Sender: menscher@alecto.physics.uiuc.edu To: gcc@gcc.gnu.org Subject: Question about template friends Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII First, let me point out that I realize this is answered in the FAQ, but I still can't figure it out. I'm attempting to overload operator<< for a template class I've written. Following the faq, I've done the following: --- from quark.h ------------------ // Forward declaration of class template class Quark; template ostream& operator<< (ostream&, const Quark); template // default to Real if no type is given class Quark { . . . //IO Functions friend ostream& operator<< <> (ostream&, const Quark&); }; --------------------------------------- and then tried to instantiate it as follows: --------from quark.C ------------------ template ostream& operator<<(ostream& os, const Quark& quark) { os << "( "; for (int counter=0; counter; template class Quark; template ostream& operator<< (ostream&, const Quark&); template ostream& operator<< (ostream&, const Quark&); ------------------------------------------ When compiling, I get the error message: quark.h:46: template-id `operator <<' for `operator <<(ostream &, const Quark &)' does not match any template declaration Could someone please tell me what's going on here, or point me to the proper place to ask this question? TIA, Damian Menscher -- --==## Grad. student & Sys. Admin. @ U. Illinois at Urbana-Champaign ##==-- --==## www.uiuc.edu/~menscher/ Ofc:(217)333-0038 ##==-- --==## Physics Dept, 1110 W Green, Urbana IL 61801 Fax:(217)333-9819 ##==-- From gcc-return-9421-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 17:25:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30501 invoked by alias); 24 Aug 1999 17:25:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30404 invoked from network); 24 Aug 1999 17:25:23 -0000 Received: from atlas.lure.u-psud.fr (193.55.24.209) by egcs.cygnus.com with SMTP; 24 Aug 1999 17:25:22 -0000 Received: from lure.u-psud.fr ([192.168.79.67]) by ariane.lure.u-psud.fr (MX V4.1 VAX) with SMTP; Tue, 24 Aug 1999 19:25:17 MET DST Message-ID: <37C2D57D.9B8BE00@lure.u-psud.fr> Date: Tue, 24 Aug 1999 19:25:17 +0200 From: Gerard Flynn Organization: LURE/CNRS X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: craig@jcb-sc.com CC: gcc@gcc.gnu.org Subject: RE: Using g77 and gdb together References: <37C2A770.C55551C6@lure.u-psud.fr> <19990824144005.22174.qmail@deer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit craig@jcb-sc.com wrote: > >In particular gdb seems to be confused about source line numbers. For > >exemple there exists a subroutine called amorti_ (AMORTI) in a given > >source > >file. The line number of the subroutine statement is 498 and the first > >executable statement is an IF at line 528 followed by an assignment at > >529. > > > >Now if in gdb I type: > >> break amorti_ > >I see: > >Breakpoint 2 at 0x80c65be: file ../beta/source/emequi.f, line 648. > > > >Line 648 is the RETURN statement at the end of the routine. > > > >If I type > >> list amorti_ > > > >gdb lists lines between 582 and 591, somewhere in the middle of the > >routine. > > > >The source file in question makes use of many INCLUDE statements some of > >which are nested. The include files, source files > >and executable are all in separate directories. It also contains > >routines containing > >ENTRY statements (although the particular routine I mentioned here does > >not.). > > Hmm. Many possible problems here. > > First, make sure you compile with `-g -O0' to turn off optimization, > at least until you verify that this produces some reasonable gdb-time > behavior. > > Now, there are several known problems with g77+gdb, some of which are > not perhaps well-understood: > > - I think GCC 2.95 (thence g77 0.5.25) still has the "skidding break" > bug I reported a couple of months back. The symptom of this bug > is that when you break on a procedure (C "function") by name, rather > than stop *before* the first executable statement, sometimes the > debugger stops after it (i.e. before the second one). > > IIRC, this is not a gdb bug, and it was discussed and suggested > was due to recent changes in flow.c. It's pretty easy to reproduce > with a small test case. > > - g77 does have some problems (I think documented at least somewhat > in the known-bugs section of the manual) tracking source line numbers > across #include, INCLUDE, or both. It's probably the case that my > view regarding this problem has been limited to its effect on > diagnostics, and that it also affects line-number info provided for > debuggers to track. I'm pretty sure the problem (which I think I > "scoped out" some two years ago!) is entirely g77-specific. > > If you study the output of using `-g -S' when compiling pertinent code, > you might learn ways to fix some of the above problems sufficiently to > at least demonstrate whether your problems are entirely due to one or > both of the above, versus some other problems. > > tq vm, (burley) It looks like the problem is coming from the nested INCLUDE "feature" of the program I'm working on. Here's a simple test case which produces odd behavior: file BIDON.H : INCLUDE 'BIDON1.H' INCLUDE 'BIDON2.H' file BIDON1.H : REAL R1 REAL R2 REAL R3 REAL R4 REAL R5 REAL R6 REAL R7 file BIDON2.H : INTEGER I1 INTEGER I2 INTEGER I3 INTEGER I4 INTEGER I5 INTEGER I6 INTEGER I7 file complex.f : PROGRAM TCMPLX IMPLICIT NONE INCLUDE 'BIDON.H' DOUBLE PRECISION A,B,C,D COMPLEX*16 CX,CY,CZ DOUBLE PRECISION V DIMENSION V(7,35) DOUBLE PRECISION TETAD,ROD,AK,W COMPLEX*16 VQ,VX,VXP,VD A=1.0D0 B=2.0D0 C=3.0D0 CY = DCMPLX(5.6D0) CZ = DCMPLX(7.8D0) C CX = A*CY + B*CZ WRITE(*,*) 'POSITION 1' W = 1.33517999 VQ = (6.04309754E-16,9.75346765E-5) V(5,2) = 0.497920662 VX = (0.790273955,0.567044628) WRITE(*,*) 'POSITION 2' ROD = 1.70000005 AK = 1.70000005 TETAD = 0.785399973 V(5,1) = 0.707108061 WRITE(*,*) 'POSITION 3' VXP = (-1.39827846,-0.370613616) VD = (0.0,0.0) CX=(W*VQ + V(5,2)*VX + ROD*AK*(TETAD-V(5,1))*VXP) * DCONJG(VD) C CX = (W*VQ + V1*VX + ROD*AK*(TETAD-V2)*VXP)*DCONJG(VD) C CX = (W*VQ + V(5,2)*VX + ROD*AK*(TETAD-V(5,1))*VXP) * DCONJG(VD) WRITE(*,*) 'CX = ',CX END If you try putting break points in this program based on line numbers and then running it, you'll probably fall of the end. In addition gdb is showing the same address for breakpoints at 3 different source positions ! Gerard Flynn From gcc-return-9422-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 18:39:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13166 invoked by alias); 24 Aug 1999 18:38:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13125 invoked from network); 24 Aug 1999 18:38:54 -0000 Received: from atlas.lure.u-psud.fr (193.55.24.209) by egcs.cygnus.com with SMTP; 24 Aug 1999 18:38:54 -0000 Received: from lure.u-psud.fr ([192.168.79.67]) by ariane.lure.u-psud.fr (MX V4.1 VAX) with SMTP; Tue, 24 Aug 1999 20:38:41 MET DST Message-ID: <37C2E6B1.8AED4A73@lure.u-psud.fr> Date: Tue, 24 Aug 1999 20:38:41 +0200 From: Gerard Flynn Organization: LURE/CNRS X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: craig@jcb-sc.com CC: gcc@gcc.gnu.org Subject: Re: Using g77 and gdb together References: <37C2A770.C55551C6@lure.u-psud.fr> <19990824144005.22174.qmail@deer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit craig@jcb-sc.com wrote: > >In particular gdb seems to be confused about source line numbers. For > >exemple there exists a subroutine called amorti_ (AMORTI) in a given > >source > >file. The line number of the subroutine statement is 498 and the first > >executable statement is an IF at line 528 followed by an assignment at > >529. > > > >Now if in gdb I type: > >> break amorti_ > >I see: > >Breakpoint 2 at 0x80c65be: file ../beta/source/emequi.f, line 648. > > > >Line 648 is the RETURN statement at the end of the routine. > > > >If I type > >> list amorti_ > > > >gdb lists lines between 582 and 591, somewhere in the middle of the > >routine. > > > >The source file in question makes use of many INCLUDE statements some of > >which are nested. The include files, source files > >and executable are all in separate directories. It also contains > >routines containing > >ENTRY statements (although the particular routine I mentioned here does > >not.). > > Hmm. Many possible problems here. > > First, make sure you compile with `-g -O0' to turn off optimization, > at least until you verify that this produces some reasonable gdb-time > behavior. > > Now, there are several known problems with g77+gdb, some of which are > not perhaps well-understood: > > - I think GCC 2.95 (thence g77 0.5.25) still has the "skidding break" > bug I reported a couple of months back. The symptom of this bug > is that when you break on a procedure (C "function") by name, rather > than stop *before* the first executable statement, sometimes the > debugger stops after it (i.e. before the second one). > > IIRC, this is not a gdb bug, and it was discussed and suggested > was due to recent changes in flow.c. It's pretty easy to reproduce > with a small test case. > > - g77 does have some problems (I think documented at least somewhat > in the known-bugs section of the manual) tracking source line numbers > across #include, INCLUDE, or both. It's probably the case that my > view regarding this problem has been limited to its effect on > diagnostics, and that it also affects line-number info provided for > debuggers to track. I'm pretty sure the problem (which I think I > "scoped out" some two years ago!) is entirely g77-specific. > > If you study the output of using `-g -S' when compiling pertinent code, > you might learn ways to fix some of the above problems sufficiently to > at least demonstrate whether your problems are entirely due to one or > both of the above, versus some other problems. > > tq vm, (burley) If I compare the output of gcc -g -S on the files I posted with and without commenting of the INCLUDE line, the .stabn line number lines are different between the two cases. If these numbers are intended to refer to the original source file then this would seem incorrect. More specifically, if the INCLUDE line is commented then the first two line number indications are : .stabn 68,0,1,.LM1-MAIN__ followed by : .stabn 68,0,13,.LM3-MAIN__. If the INCLUDE is uncommented the second such line becomes : .stabn 68,0,29,.LM3-MAIN__. The total number of included lines is 14 so the difference doesn't correspond exactly but it's close. Gerard Flynn From gcc-return-9423-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 19:01:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18605 invoked by alias); 24 Aug 1999 19:01:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18575 invoked from network); 24 Aug 1999 19:01:29 -0000 Received: from smtp.interlog.com (root@207.34.202.37) by egcs.cygnus.com with SMTP; 24 Aug 1999 19:01:29 -0000 Received: from crjnt2 (cj.interlog.com [199.212.157.174]) by smtp.interlog.com (8.9.1/8.9.1) with SMTP id PAA16777 for ; Tue, 24 Aug 1999 15:01:26 -0400 (EDT) Message-Id: <3.0.32.19990824150306.009a5ba0@mail.interlog.com> X-Sender: cj@mail.interlog.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 24 Aug 1999 15:03:07 -0400 To: gcc@gcc.gnu.org From: "Christopher R. Jones" Subject: Re: Strange behaviour in C++... Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Using a 180 Pentium Pro: >From Solairs Intel, gcc 2.95.1, built with gcc 2.8: Alfa 1=3D42 Alfa 2=3D42 BetaAlfa=3D42 Alfa 1=3D47 Alfa 2=3D47 GammaAlfa=3D47 AlfaGammaAlfa=3D47 >From Linux Redhat 5.2, gcc 2.95.1, built with egcs 1.1.2: Alfa 1=3D42 Alfa 2=3D42 BetaAlfa=3D42 Alfa 1=3D47 Alfa 2=3D134580833 GammaAlfa=3D47 AlfaGammaAlfa=3D47 At 04:54 PM 8/24/99 +0200, Fredrik =D6hrstr=F6m wrote: > >The code below compiled with 2.95.1 (19990816)=20 >(on a RedHat 5.2 system i386) produces: > >Alfa 1=3D42 >Alfa 2=3D42 >BetaAlfa=3D42 >Alfa 1=3D47 >Alfa 2=3D134580865 >GammaAlfa=3D47 >AlfaGammaAlfa=3D47 > >Shouldn't Alfa 2 be 47 in the second creation? > >Cheers >Fredrik > >--------------------------------------------------------- > > >#include > >struct Alfa >{ > virtual int alfa() =3D 0; >}; > >struct Beta >{}; > >struct Gamma >{}; > >struct Alfa_i : public virtual Alfa =20 >{ > int a; > > Alfa_i (int aa) : a (aa) > { > } =20 > =20 > int alfa () > { > return a; > } >}; > >struct Beta_i : public virtual Beta, > public Alfa_i >{ > Beta_i (int bb) : Alfa_i (bb) > { > cerr << "Alfa 1=3D" << alfa ()<< endl; > Alfa *a =3D this; > cerr << "Alfa 2=3D" << a->alfa ()<< endl; =20 > } >}; > >struct Gamma_i : public virtual Gamma, > public Beta_i >{ > Gamma_i (int cc)=20 > : Beta_i (cc) > {} >}; > > =20 >int main () >{ > Beta_i *b =3D new Beta_i (42); > cerr << "BetaAlfa=3D" << b->alfa() << endl; > > Gamma_i *g =3D new Gamma_i (47); > cerr << "GammaAlfa=3D" << g->alfa() << endl; > > Alfa *a =3D g; > cerr << "AlfaGammaAlfa=3D" << a->alfa() << endl; =20 >} > > > > > Christopher R. Jones, P.Eng. 14 Oneida Avenue Toronto, Ontario M5J 2E3 Tel. 416 203-7465 Fax. 416 203-3044 Email cj@interlog.com From gcc-return-9424-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 19:20:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20414 invoked by alias); 24 Aug 1999 19:19:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20387 invoked from network); 24 Aug 1999 19:19:46 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 24 Aug 1999 19:19:46 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id VAA01137; Tue, 24 Aug 1999 21:18:17 +0200 Message-ID: <37C2EFF9.CCD2F3CD@moene.indiv.nluug.nl> Date: Tue, 24 Aug 1999 21:18:17 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: ronis@onsager.chem.mcgill.ca CC: gcc@gcc.gnu.org Subject: Re: Constants and -ffast-math References: <199908232141.RAA14169@ronispc.chem.mcgill.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Ronis wrote: > I have all floating-point's declared as doubles, except for explicit > floating point constants (like 1.0 or 0.0). > I was under the impression that 1.0 defaults to a double; In what language ? (I think this is true in K&R C, but it has been a while) ... Note that this doesn't make any difference for the constants 1.0 and 0.0 (which are exactly representable), but it does make a difference for, e.g., 0.1. In Fortran, a constant that isn't in any way qualified, is taken to be default REAL. This translates to a 4 byte floating point number on all targets GCC/g77 supports, AFAIK. > does this > change with --fast-math? It shouldn't, but I'm running out of ideas. No. > As long as I'm at it, could someone amplify on what exactly > --fast-math does, beyond the information in the gcc info docs. I think the only way to really find out is to search for all the places in the compiler where flag_fast_math is tested ... -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-9425-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 20:35:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4314 invoked by alias); 24 Aug 1999 20:35:14 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4299 invoked from network); 24 Aug 1999 20:35:10 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 24 Aug 1999 20:35:10 -0000 Received: from marathon.synopsys.com (marathon.synopsys.com [146.225.100.41]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id NAA06921; Tue, 24 Aug 1999 13:34:06 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by marathon.synopsys.com (8.8.8/8.8.8) with SMTP id NAA18888; Tue, 24 Aug 1999 13:34:05 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id NAA20596; Tue, 24 Aug 1999 13:34:05 -0700 Message-Id: <199908242034.NAA20596@atrus.synopsys.com> Subject: Re: Constants and -ffast-math To: toon@moene.indiv.nluug.nl (Toon Moene) Date: Tue, 24 Aug 99 13:34:05 PDT Cc: ronis@onsager.chem.mcgill.ca, gcc@gcc.gnu.org In-Reply-To: <37C2EFF9.CCD2F3CD@moene.indiv.nluug.nl>; from "Toon Moene" at Aug 24, 99 9:18 pm X-Mailer: ELM [version 2.3 PL11] > > I have all floating-point's declared as doubles, except for explicit > > floating point constants (like 1.0 or 0.0). > > > I was under the impression that 1.0 defaults to a double; > > In what language ? (I think this is true in K&R C, but it has been a > while) ... Yes, 1.0 is a double, in ANSI C and C++. If you want a single-precision literal, type 1.0F. From gcc-return-9426-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 20:41:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6126 invoked by alias); 24 Aug 1999 20:41:46 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6109 invoked from network); 24 Aug 1999 20:41:38 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 24 Aug 1999 20:41:38 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id QAA28734 for ; Tue, 24 Aug 1999 16:39:58 -0400 Message-ID: <37C304AD.D767F7E8@moberg.com> Date: Tue, 24 Aug 1999 20:46:37 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jason Merrill wrote: > > >>>>> George T Talbot writes: > > > Jason Merrill wrote: > >> > >> No; cleanups are registered at compile time in the dwarf2 model. You'll > >> need to extend the C frontend to add the notion of cleanups, like a try > >> ... finally construct, or a cleanup block construct. > > > Ugh. This is starting to get beyond my skill level. I can do the C > > library stuff, but I'm not sure I understand how to extend the compiler > > this way. > > Actually, the simplest approach would be to make them builtin functions, > __builtin_cleanup_push (routine, arg) and __builtin_cleanup_pop (execute). > You would call expand_eh_region_start_tree in stmt.c to register the > cleanup, and if execute is true when popping, extract the cleanup info from > the ehstack and run it directly. It would be hard to map the existing API > onto try ... finally. Actually, I think the #define's using try and catch would look something like this: #define pthread_cleanup_push(routine, arg) \ { \ void *__arg = arg; \ void (*__routine)(void *) = routine; \ try \ { #define pthread_cleanup_pop(execute) \ } \ catch (...) \ { \ __routine(__arg); \ throw; \ } \ if (execute) __routine(__arg); \ } Now, the question is, would it be easier to make the existing try and catch legal in a C program, since that's already built into the compiler, or would it be easier to add __builtin_cleanup_push() and __builtin_cleanup_pop()? Making try, catch, and throw available in C would be a nice GNU extension, eh? ;^) I could then put: throw POSIX_cancel; in the linuxthreads library directly, for unwinding the stack at deferred cancellation, rather than having a .cc file in there (horrors). What's the chance of getting such a patch into the mainline distribution? Is that too radical? -- George T. Talbot From gcc-return-9427-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 20:53:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8464 invoked by alias); 24 Aug 1999 20:53:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8441 invoked from network); 24 Aug 1999 20:52:58 -0000 Received: from citycenter.citilink.com (root@209.98.8.5) by egcs.cygnus.com with SMTP; 24 Aug 1999 20:52:58 -0000 Received: from foshay.citilink.com (jstern@foshay.citilink.com [209.98.8.9]) by citycenter.citilink.com (8.8.8/8.7.5) with ESMTP id PAA18448; Tue, 24 Aug 1999 15:50:56 -0500 (CDT) Received: (from jstern@localhost) by foshay.citilink.com (8.8.8/8.7.5) id PAA08531; Tue, 24 Aug 1999 15:52:44 -0500 (CDT) Date: Tue, 24 Aug 1999 15:52:44 -0500 (CDT) From: Josh Stern Posted-Date: Tue, 24 Aug 1999 15:52:44 -0500 (CDT) Message-Id: <199908242052.PAA08531@foshay.citilink.com> To: gcc@gcc.gnu.org, george@moberg.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads >Making try, catch, and throw available in C would be a nice GNU >extension, >eh? ;^) I could then put: > > throw POSIX_cancel; > >in the linuxthreads library directly, for unwinding the stack at >deferred >cancellation, rather than having a .cc file in there (horrors). If this extension would allow exceptions to be thrown from Unix signal handlers, that would be a very cool feature for even non-threaded programs. - Josh From gcc-return-9428-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 20:57:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9935 invoked by alias); 24 Aug 1999 20:57:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9919 invoked from network); 24 Aug 1999 20:57:13 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 24 Aug 1999 20:57:13 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id QAA28860; Tue, 24 Aug 1999 16:55:26 -0400 Message-ID: <37C3084C.BC7CBE89@moberg.com> Date: Tue, 24 Aug 1999 21:02:04 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ulrich Drepper CC: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ulrich Drepper wrote: > > "George T. Talbot" writes: > > > I don't know. Mr. Drepper, can you tell us what was measured? Was this > > with the new exception model or the old setjmp()/longjmp() exception > > model? > > I don't remember. One of the things which was measured for sure is > code/data size and this went up. OK...I just patched glibc 2.1.1pre2 (the one that comes with Mandrake Linux) so that -fexceptions would be added to C compiles. The size went from 1.2MB to 1.4MB. Is that an acceptable size increase? I don't have enough experience with glibc customers to guage that. The additional size increase appears to be from .eh_frame sections. As to performance, do you have a standard method of measuring overall performance? I noticed that the testsuite directory was empty, with a notice about copyright problems. Is the testsuite used to measure performance? If not, what would I use to measure performance and whether/how much -fexceptions changes performance? By the way, I'm using egcs 1.1.2 for now. Eventually, when I have a version of glibc that can be compiled with 2.95.1, I intend to recompile with that for comparison. -- George T. Talbot From gcc-return-9429-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 21:03:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11384 invoked by alias); 24 Aug 1999 21:02:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11366 invoked from network); 24 Aug 1999 21:02:51 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 24 Aug 1999 21:02:51 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id OAA09643; Tue, 24 Aug 1999 14:01:52 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id OAA16226; Tue, 24 Aug 1999 14:01:52 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id OAA21795; Tue, 24 Aug 1999 14:01:51 -0700 Message-Id: <199908242101.OAA21795@atrus.synopsys.com> Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads To: jstern@citilink.com (Josh Stern) Date: Tue, 24 Aug 99 14:01:51 PDT Cc: gcc@gcc.gnu.org, george@moberg.com In-Reply-To: <199908242052.PAA08531@foshay.citilink.com>; from "Josh Stern" at Aug 24, 99 3:52 pm X-Mailer: ELM [version 2.3 PL11] > >Making try, catch, and throw available in C would be a nice GNU > >extension, ... Josh writes: > If this extension would allow exceptions to be thrown from > Unix signal handlers, that would be a very cool feature > for even non-threaded programs. It wouldn't, since we don't support that in C++ either. The problem is that signals can happen anywhere. Consider char * buf = 0; try { buf = malloc(buf_size); } catch (SIGNAL) { if (buf) free(buf); } This code has a race and a leak, and there's no way to write it correctly, because the signal could come after malloc has allocated memory but before buf is assigned. I suppose there could be a mechanism to queue signals and throw exceptions at "safe" points. From gcc-return-9430-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 21:09:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12515 invoked by alias); 24 Aug 1999 21:09:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12497 invoked from network); 24 Aug 1999 21:09:15 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 24 Aug 1999 21:09:15 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA04936; Tue, 24 Aug 1999 14:09:14 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id OAA10385; Tue, 24 Aug 1999 14:09:14 -0700 To: "George T. Talbot" Cc: gcc@gcc.gnu.org Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BAD6A5.315C3625@moberg.com> <37BC5244.3B5E6510@moberg.com> <37BC5B0C.93FDF45F@moberg.com> <37BC612F.C7A2E9A0@moberg.com> <37BC7C90.4A40750F@moberg.com> <37C30475.DFB7881D@moberg.com> From: Jason Merrill Date: 24 Aug 1999 14:09:14 -0700 In-Reply-To: "George T. Talbot"'s message of "Tue, 24 Aug 1999 20:45:41 +0000" Message-ID: Lines: 62 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> George T Talbot writes: >> Actually, the simplest approach would be to make them builtin functions, >> __builtin_cleanup_push (routine, arg) and __builtin_cleanup_pop (execute). >> You would call expand_eh_region_start_tree in stmt.c to register the >> cleanup, and if execute is true when popping, extract the cleanup info from >> the ehstack and run it directly. It would be hard to map the existing API >> onto try ... finally. > Actually, I think the #define's using try and catch would look something > like this: > #define pthread_cleanup_push(routine, arg) \ > { \ > void *__arg = arg; \ > void (*__routine)(void *) = routine; \ > try \ > { > #define pthread_cleanup_pop(execute) \ > } \ > catch (...) \ > { \ > __routine(__arg); \ > throw; \ > } \ > if (execute) __routine(__arg); \ > } Works for me. > Now, the question is, would it be easier to make the existing try and > catch legal in a C program, since that's already built into the > compiler, or would it be easier to add __builtin_cleanup_push() and > __builtin_cleanup_pop()? The latter would probably be easier; the former would be preferable, since the syntax already exists. Though we'd want to use __try and __catch to avoid adding keywords in userland. > Making try, catch, and throw available in C would be a nice GNU > extension, eh? ;^) I could then put: > throw POSIX_cancel; > in the linuxthreads library directly, for unwinding the stack at > deferred cancellation, rather than having a .cc file in there (horrors). I think I'd prefer to avoid adding throw support to C; try and catch (...) seem sufficient. We don't really need to be able to throw and catch exceptions, just run cleanup actions when another language throws through us. > What's the chance of getting such a patch into the mainline > distribution? Is that too radical? Seems plausible to me, but then I'm a C++ guy...:) BTW, please CC the list on this discussion; there's no reason to keep it private. Jason From gcc-return-9431-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 21:10:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13200 invoked by alias); 24 Aug 1999 21:10:36 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13163 invoked from network); 24 Aug 1999 21:10:35 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 24 Aug 1999 21:10:35 -0000 Received: from otr.mynet (dhcp-sv-0H.cygnus.com [205.180.231.77]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA05030; Tue, 24 Aug 1999 14:10:32 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.9.3/8.9.3/ud-990718) id OAA05774; Tue, 24 Aug 1999 14:08:05 -0700 To: "George T. Talbot" Cc: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Ulrich Drepper Date: 24 Aug 1999 14:08:05 -0700 In-Reply-To: "George T. Talbot"'s message of "Tue, 24 Aug 1999 21:02:04 +0000" Message-ID: Lines: 22 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Big Bend" "George T. Talbot" writes: > The size went from 1.2MB to 1.4MB. Is that an acceptable size > increase? Certainly not. This increase is completely unused in most cases. > As to performance, do you have a standard method of measuring overall > performance? No. > I noticed that the testsuite directory was empty, with a notice > about copyright problems. Is the testsuite used to measure > performance? You are not talking about glibc? We have no testsuite directory. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gcc-return-9432-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 21:17:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15625 invoked by alias); 24 Aug 1999 21:17:52 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15587 invoked from network); 24 Aug 1999 21:17:49 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 24 Aug 1999 21:17:49 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id RAA17371 for ; Tue, 24 Aug 1999 17:17:46 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (burley@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id RAA06639 for ; Tue, 24 Aug 1999 17:15:27 -0400 (EDT) Received: (qmail 24296 invoked by uid 500); 24 Aug 1999 21:13:51 -0000 Date: 24 Aug 1999 21:13:51 -0000 Message-ID: <19990824211351.24295.qmail@deer> To: flynn@lure.u-psud.fr CC: gcc@gcc.gnu.org cc: craig@jcb-sc.com In-reply-to: <37C2E6B1.8AED4A73@lure.u-psud.fr> (message from Gerard Flynn on Tue, 24 Aug 1999 20:38:41 +0200) Subject: Re: Using g77 and gdb together References: <37C2A770.C55551C6@lure.u-psud.fr> <19990824144005.22174.qmail@deer> <37C2E6B1.8AED4A73@lure.u-psud.fr> >The total number of included lines is 14 so the difference doesn't correspond >exactly but it's close. Yup, IIRC the lexer "assigns" what I think are called "master line numbers" to things like switching from one source file to another. This might, for example, ease the handling of files not ending with a newline (which I used to hate as a coder, but have since realized are, according to "my" new rules for good plaintext-file design, entirely legit, since the absence of a final newline makes no difference in how a file is typically imaged). My recall of the lexer issues surrounding this is rather faint, and I'm strongly resisting looking into it again. Especially since the existing code sits squarely in the cross-hairs of the rewrite I was proposing (and would like to complete at least part of, if only to ease moving tests out of my test suite into the GCC/g77 testsuite -- that perhaps needs more explanation than I'm willing to give at this time, suffice to say, I've wanted a "stand-alone lexer", as well as subsequent phases, for years now, independent of their potential utility in the rewrite of the g77 front end). What I am thinking, though, is that the problems tracking line numbers show up only when doing at least *two* levels of INCLUDE, rather than just one. That might be enough to spur someone to do a little digging and perhaps find an easier solution than I thought was necessary a couple of years ago, or to just implement that. tq vm, (burley) From gcc-return-9433-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 21:17:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15634 invoked by alias); 24 Aug 1999 21:17:54 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15604 invoked from network); 24 Aug 1999 21:17:50 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 24 Aug 1999 21:17:50 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id RAA29034; Tue, 24 Aug 1999 17:16:08 -0400 Message-ID: <37C30D28.6724EC6F@moberg.com> Date: Tue, 24 Aug 1999 21:22:48 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ulrich Drepper CC: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ulrich Drepper wrote: > > "George T. Talbot" writes: > > > I don't know. Mr. Drepper, can you tell us what was measured? Was this > > with the new exception model or the old setjmp()/longjmp() exception > > model? > > I don't remember. One of the things which was measured for sure is > code/data size and this went up. My apologies if this is a duplicate. I patched glibc 2.1.1pre2 so that it's compiled with -fexceptions. This increased the size of libc.so from 1.2M to 1.4M. Is this size increase acceptable for a change to the mainline distribution? I don't have the experience with the customers of glibc to assess that. How would I go about measuring the performance penalty of -fexceptions in normal C code? When I install the recompiled library, everything seems to be the same, and compiles seem to take the same amount of time. I will measure a large compile (maybe the kernel or something) and post to the lists when I've done so. I noticed that the testsuite directory is empty with a notice about copyright/patent issues. Would I measure performance with the testsuite? Is there another method you would prefer I use? What would be the cutoff at which a change wouldn't be accepted into a mainline distribution with respect to the performance impact of -fexceptions? In other words, at what point does the performance penalty of -fexceptions become unacceptable and how do I measure it? P.S.: I'm using egcs 1.1.2 to compile the C library right now, as that's what the configure script wants. When I get a version of the C library that can be compiled with gcc 2.95.1, I can try that, too. -- George T. Talbot From gcc-return-9434-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 21:21:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17115 invoked by alias); 24 Aug 1999 21:21:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17063 invoked from network); 24 Aug 1999 21:21:08 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 24 Aug 1999 21:21:08 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA05864; Tue, 24 Aug 1999 14:21:07 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id OAA10497; Tue, 24 Aug 1999 14:21:07 -0700 To: Josh Stern Cc: gcc@gcc.gnu.org, george@moberg.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <199908242052.PAA08531@foshay.citilink.com> From: Jason Merrill Date: 24 Aug 1999 14:21:07 -0700 In-Reply-To: Josh Stern's message of "Tue, 24 Aug 1999 15:52:44 -0500 (CDT)" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Josh Stern writes: >> Making try, catch, and throw available in C would be a nice GNU >> extension, eh? ;^) I could then put: >> >> throw POSIX_cancel; >> >> in the linuxthreads library directly, for unwinding the stack at >> deferred cancellation, rather than having a .cc file in there >> (horrors). > If this extension would allow exceptions to be thrown from > Unix signal handlers, that would be a very cool feature > for even non-threaded programs. That's an entirely separate question; asynchronous exceptions are very hard to get right. George is only talking about deferred cancellation, which I presume is initiated by the thread. Jason From gcc-return-9435-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 21:25:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19092 invoked by alias); 24 Aug 1999 21:25:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19050 invoked from network); 24 Aug 1999 21:25:43 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 24 Aug 1999 21:25:43 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id RAA29172; Tue, 24 Aug 1999 17:23:56 -0400 Message-ID: <37C30EFC.84AD5CCF@moberg.com> Date: Tue, 24 Aug 1999 21:30:36 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: Josh Stern CC: gcc@gcc.gnu.org Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <199908242052.PAA08531@foshay.citilink.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Josh Stern wrote: > > >Making try, catch, and throw available in C would be a nice GNU > >extension, > >eh? ;^) I could then put: > > > > throw POSIX_cancel; > > > >in the linuxthreads library directly, for unwinding the stack at > >deferred > >cancellation, rather than having a .cc file in there (horrors). > > If this extension would allow exceptions to be thrown from > Unix signal handlers, that would be a very cool feature > for even non-threaded programs. > > - Josh Not sure. With pthread_cancel(), in deferred cancellation mode, I'm guaranteed the exception would only be thrown at cancellation points. -- George T. Talbot From gcc-return-9436-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 21:53:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22557 invoked by alias); 24 Aug 1999 21:53:37 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22517 invoked from network); 24 Aug 1999 21:53:32 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 24 Aug 1999 21:53:32 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id RAA29431; Tue, 24 Aug 1999 17:51:50 -0400 Message-ID: <37C31585.B71A8BA2@moberg.com> Date: Tue, 24 Aug 1999 21:58:29 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ulrich Drepper CC: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ulrich Drepper wrote: > > "George T. Talbot" writes: > > > The size went from 1.2MB to 1.4MB. Is that an acceptable size > > increase? > > Certainly not. This increase is completely unused in most cases. I just had a thought...all I care about is enabling -fexceptions for any function which is a cancellation point in the C library, or any function that calls a cancellation point in the C library. Maybe there's a way to narrow down which functions get -fexceptions applied to them. I noticed that each function is in its own file, which is a really good idea and should make that a bit easier. (Does such a list exist already?) -- George T. Talbot From gcc-return-9437-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 21:56:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23539 invoked by alias); 24 Aug 1999 21:56:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23458 invoked from network); 24 Aug 1999 21:55:57 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 24 Aug 1999 21:55:57 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA08096; Tue, 24 Aug 1999 14:55:54 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id OAA13747; Tue, 24 Aug 1999 14:55:53 -0700 To: drepper@cygnus.com (Ulrich Drepper) Cc: "George T. Talbot" , Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> From: Jason Merrill Date: 24 Aug 1999 14:55:53 -0700 In-Reply-To: Ulrich Drepper's message of "24 Aug 1999 14:08:05 -0700" Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Ulrich Drepper writes: > "George T. Talbot" writes: >> The size went from 1.2MB to 1.4MB. Is that an acceptable size >> increase? > Certainly not. This increase is completely unused in most cases. Is that a problem? If it's not used, it won't be loaded. Jason From gcc-return-9438-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 22:00:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25004 invoked by alias); 24 Aug 1999 22:00:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24926 invoked from network); 24 Aug 1999 22:00:19 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 24 Aug 1999 22:00:19 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA17834; Tue, 24 Aug 1999 15:00:15 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id PAA01733; Tue, 24 Aug 1999 15:00:15 -0700 (PDT) Date: Tue, 24 Aug 1999 15:00:15 -0700 (PDT) Message-Id: <199908242200.PAA01733@kankakee.wrs.com> To: gcc@gcc.gnu.org, george@moberg.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads > Date: Tue, 24 Aug 1999 20:46:37 +0000 > From: "George T. Talbot" > Now, the question is, would it be easier to make the existing try > and catch legal in a C program, This will be done at some point. Given the existence of this, the other solution isn't as good. I think it is a small number of lines to add it, might as well add it. You can rip some/most of those lines from the C++ frontennd. Brownie points if you can move common parts to c-common.c, instead of just copying them. > What's the chance of getting such a patch into the mainline > distribution? About 1. I don't think there is much you can do wrong (please don't prove me wrong :-)). From gcc-return-9439-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 22:02:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25696 invoked by alias); 24 Aug 1999 22:02:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25658 invoked from network); 24 Aug 1999 22:02:12 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 24 Aug 1999 22:02:12 -0000 Received: from otr.mynet (dhcp-sv-0H.cygnus.com [205.180.231.77]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA08553; Tue, 24 Aug 1999 15:02:06 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.9.3/8.9.3/ud-990718) id OAA05889; Tue, 24 Aug 1999 14:59:40 -0700 To: Jason Merrill Cc: "George T. Talbot" , Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Ulrich Drepper Date: 24 Aug 1999 14:59:39 -0700 In-Reply-To: Jason Merrill's message of "24 Aug 1999 14:55:53 -0700" Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Big Bend" Jason Merrill writes: > > Certainly not. This increase is completely unused in most cases. > > Is that a problem? If it's not used, it won't be loaded. If yu look through the Makefile you'll see that there is already support for -fexception. I used it once and people complained about the size increase. It's nothing I make up myself. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gcc-return-9440-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 22:04:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26410 invoked by alias); 24 Aug 1999 22:04:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26379 invoked from network); 24 Aug 1999 22:03:58 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 24 Aug 1999 22:03:58 -0000 Received: from otr.mynet (dhcp-sv-0H.cygnus.com [205.180.231.77]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA08685; Tue, 24 Aug 1999 15:03:57 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.9.3/8.9.3/ud-990718) id PAA05892; Tue, 24 Aug 1999 15:01:30 -0700 To: "George T. Talbot" Cc: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> <37C31585.B71A8BA2@moberg.com> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Ulrich Drepper Date: 24 Aug 1999 15:01:30 -0700 In-Reply-To: "George T. Talbot"'s message of "Tue, 24 Aug 1999 21:58:29 +0000" Message-ID: Lines: 24 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Big Bend" "George T. Talbot" writes: > I just had a thought...all I care about is enabling -fexceptions for any > function which is a cancellation point in the C library, or any function > that > calls a cancellation point in the C library. Maybe there's a way to > narrow > down which functions get -fexceptions applied to them. I noticed that > each > function is in its own file, which is a really good idea and should make > that a bit easier. (Does such a list exist already?) You have to find all cancelation point and al functions which directly or indirectly use callback functions (which could be C++). This is not trivial. And in addition, to justify the changes, you'll have to come up with a scheme how the exception handling can be used in C to implement the POSIX cancelation stuff. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gcc-return-9441-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 22:12:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29283 invoked by alias); 24 Aug 1999 22:11:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29166 invoked from network); 24 Aug 1999 22:11:25 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 24 Aug 1999 22:11:25 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id SAA29596; Tue, 24 Aug 1999 18:09:43 -0400 Message-ID: <37C319B7.7ACE964C@moberg.com> Date: Tue, 24 Aug 1999 22:16:23 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ulrich Drepper CC: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> <37C31585.B71A8BA2@moberg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ulrich Drepper wrote: > > "George T. Talbot" writes: > > > I just had a thought...all I care about is enabling -fexceptions for any > > function which is a cancellation point in the C library, or any function > > that > > calls a cancellation point in the C library. Maybe there's a way to > > narrow > > down which functions get -fexceptions applied to them. I noticed that > > each > > function is in its own file, which is a really good idea and should make > > that a bit easier. (Does such a list exist already?) > > You have to find all cancelation point and al functions which directly > or indirectly use callback functions (which could be C++). This is > not trivial. I just looked and all my hair just fell out. ;^) You're right. It's a big list. Not too sure what to do about that yet... > And in addition, to justify the changes, you'll have to come up with a > scheme how the exception handling can be used in C to implement the > POSIX cancelation stuff. I suggested on the gcc@gcc.gnu.org list extending the C compiler a bit to support try and catch in C (with different names to avoid clashes), and the people on that list liked the idea a lot for various reasons. -- George T. Talbot P.S. It was good to meet you at LinuxWorld. Your talks on glibc and the linker were great. From gcc-return-9442-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 22:13:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29836 invoked by alias); 24 Aug 1999 22:13:09 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29773 invoked from network); 24 Aug 1999 22:13:00 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 24 Aug 1999 22:13:00 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id SAA29602; Tue, 24 Aug 1999 18:11:16 -0400 Message-ID: <37C31A14.6817336D@moberg.com> Date: Tue, 24 Aug 1999 22:17:56 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ulrich Drepper CC: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ulrich Drepper wrote: > > "George T. Talbot" writes: > > > The size went from 1.2MB to 1.4MB. Is that an acceptable size > > increase? > > Certainly not. This increase is completely unused in most cases. What would be an acceptable size increase? Did the people who complained say what would be acceptable or did they just complain? ;^) > > As to performance, do you have a standard method of measuring overall > > performance? > > No. What methods do you guys use now to determine what is and what isn't an acceptable performance hit when, say, you're experimenting with different compiler optimization flags? I'm trying to get an idea of what is and what isn't acceptable. I have no problem doing the hard work of implementing a fix to pthread_cancel() under Linux, and I have no problem doing the hard work of measurement, but I need some objective criteria for doing the measurement so I don't walk down a dead-end path. -- George T. Talbot From gcc-return-9443-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 22:14:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30232 invoked by alias); 24 Aug 1999 22:14:07 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30118 invoked from network); 24 Aug 1999 22:13:55 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 24 Aug 1999 22:13:55 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id SAA29613; Tue, 24 Aug 1999 18:12:16 -0400 Message-ID: <37C31A50.DB3FE0D7@moberg.com> Date: Tue, 24 Aug 1999 22:18:56 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org, glibc-alpha@sourceware.cygnus.com Subject: Thread cancellation and exceptions--where I am now... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For anyone interested: I've been working on improved interoperability between pthreads and C++ on Linux. At this point, I've patched the C library to support exceptions by compiling it with -fexceptions. I have modified my C++ program to throw an exception in a cancellation handler which is caught at the top-level thread function. This works and does what I want it to do, which is unwind the stack at thread cancellation, calling destructors for any objects on the stack. Ideally, I'd like to build this into the linuxthreads section of the C library so that pthread_cancel() "just does" what a C++ or Ada programmer would expect. I'm working on a patch to the C library now, although it probably will require some more compiler support--the ability to use try {}, catch {} and throw, or some reasonable variant hooked into the exception mechanism comes to mind. I will, of course, make my patches available as soon as they're clean and working. The reason I continue to talk about this issue is that, the more I read about the POSIX standard for threads, the more it becomes clear that the intention of the standard's author is that pthread_cancel_push() and pthread_cancel_pop() would be integrated into the platform's native exception handling mechanism. The reason for this is interoperability with languages supporting native exception handling. The ones I know of so far are C++ and Ada. I also think that Modula2(?) has native exception handling. (Does gcj use native exception handling when compiling Java to native code, too?) When any of these languages are used in a program that uses pthread_cancel() in deferred cancellation mode, the program will not work correctly. [It's really really really hard to present threads as objects in these languages if exception handling doesn't work when a thread is cancelled, and one major vendor (MS) ducks the issue entirely by saying that cancelling a thread causes resource leaks, so don't do it.] I can't figure out any other way to get pthread_cancel() to work with languages that support exceptions than to recompile the C library with -fexceptions and to patch the linuxthreads portion to throw an exception as part of handling a deferred cancel in a thread. I have a rudimentary patch for doing this now, and it works, but unwinds C++ destructors after running all the pthread_cancel_push() handlers, which isn't really correct. A more ambitious and correct patch would change pthread_cancel_push() and pthread_cancel_pop() to use exception handling in regular C programs, but I'll have to patch the compiler to get this to work. -- George T. Talbot From gcc-return-9444-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 22:19:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31865 invoked by alias); 24 Aug 1999 22:18:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31803 invoked from network); 24 Aug 1999 22:18:55 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 24 Aug 1999 22:18:55 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.9.3/8.9.3) with ESMTP id PAA29779; Tue, 24 Aug 1999 15:23:34 -0700 To: jason@cygnus.com Cc: drepper@cygnus.com, george@moberg.com, kriol@fnal.gov, gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads In-Reply-To: References: <37C3084C.BC7CBE89@moberg.com> X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990824152334N.mitchell@codesourcery.com> Date: Tue, 24 Aug 1999 15:23:34 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 15 >>>>> "Jason" == Jason Merrill writes: >> "George T. Talbot" writes: >>> The size went from 1.2MB to 1.4MB. Is that an acceptable size >>> increase? >> Certainly not. This increase is completely unused in most >> cases. Since glibc is usually dynamically linked, I don't see why 200K, on disk, is a big deal at all. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-9445-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 22:21:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 558 invoked by alias); 24 Aug 1999 22:21:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 507 invoked from network); 24 Aug 1999 22:21:43 -0000 Received: from citycenter.citilink.com (root@209.98.8.5) by egcs.cygnus.com with SMTP; 24 Aug 1999 22:21:43 -0000 Received: from foshay.citilink.com (jstern@foshay.citilink.com [209.98.8.9]) by citycenter.citilink.com (8.8.8/8.7.5) with ESMTP id RAA25466; Tue, 24 Aug 1999 17:19:35 -0500 (CDT) Received: (from jstern@localhost) by foshay.citilink.com (8.8.8/8.7.5) id RAA10662; Tue, 24 Aug 1999 17:21:20 -0500 (CDT) Date: Tue, 24 Aug 1999 17:21:20 -0500 (CDT) From: Josh Stern Posted-Date: Tue, 24 Aug 1999 17:21:20 -0500 (CDT) Message-Id: <199908242221.RAA10662@foshay.citilink.com> To: jbuck@synopsys.COM, jstern@citilink.com Cc: gcc@gcc.gnu.org, george@moberg.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Joe writes: >Josh writes: >> If this extension would allow exceptions to be thrown from >> Unix signal handlers, that would be a very cool feature >> for even non-threaded programs. >It wouldn't, since we don't support that in C++ either. The problem >is that signals can happen anywhere. Consider > > char * buf = 0; > try { > buf = malloc(buf_size); > } > catch (SIGNAL) { > if (buf) > free(buf); > } > >This code has a race and a leak, and there's no way to write it correctly, >because the signal could come after malloc has allocated memory but before >buf is assigned. I understand the example, and also (I think) Jason's comment that asynchronous exceptions are very hard to get right. Just to pursue this a little bit however... I would diagnose the problem above as an inadequate implementation of malloc() (relative to use in a program that could throw from a signal handler). An acceptable malloc for such a program would have to catch the SIGNAL exception at a point where it still had access to the internal data structures that get adjusted during the memory allocation. Offhand, I don't see why it would so difficult to write such a malloc. - Josh From gcc-return-9446-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 22:36:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5030 invoked by alias); 24 Aug 1999 22:36: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5005 invoked from network); 24 Aug 1999 22:36:25 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 24 Aug 1999 22:36:25 -0000 Received: from otr.mynet (dhcp-sv-0H.cygnus.com [205.180.231.77]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA11209; Tue, 24 Aug 1999 15:36:23 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.9.3/8.9.3/ud-990718) id PAA05991; Tue, 24 Aug 1999 15:33:56 -0700 To: "George T. Talbot" Cc: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> <37C31A14.6817336D@moberg.com> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Ulrich Drepper Date: 24 Aug 1999 15:33:56 -0700 In-Reply-To: "George T. Talbot"'s message of "Tue, 24 Aug 1999 22:17:56 +0000" Message-ID: Lines: 98 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Big Bend" "George T. Talbot" writes: > What would be an acceptable size increase? Did the people who > complained say what would be acceptable or did they just complain? > ;^) The latter, of course. > What methods do you guys use now to determine what is and what isn't > an acceptable performance hit when, say, you're experimenting with > different compiler optimization flags? I don't have to run performance data. If a feature effects everybody and is hardly used by anybody it's not worth it. If the effect is minimal (i.e., a handful of additional assembler instruction or a few bytes of data where needed) this is ok. But simply enabling fexceptions is not. > I'm trying to get an idea of what is and what isn't acceptable. I > have no problem doing the hard work of implementing a fix to > pthread_cancel() under Linux, and I have no problem doing the hard > work of measurement, but I need some objective criteria for doing > the measurement so I don't walk down a dead-end path. I like the idea of using the exception mechanism to handle cancelation even in C. So what has to be done is: - implement a usable interface to the exception handling in gcc (not g++). It must be possible to define macros named pthread_cleanup_push() and pthread_cleanup_pop() and use them like this: pthread_cleanup_push (func, arg); ... do lots of work ... if (some condition) { ... do what is necessary to leave the frame ... return; } ... more work ... pthread_cleanup_pop (doit); This roughly has to be converted to something like: try { ... do lots of work ... if (some condition) return; ... more work ... if (doit) throw (_posix_cancelation_exception_object); // Alternatively do the call directly: // func (arg); }; catch (_POSIX_CANCELATION_EXCEPTION &exc) { func (arg); }; I.e.: + leaving the frame must somehow be handled + the function to be called (and it's always only one function) is named in the push call at the beginning (contrary to the C++ syntax) + one must be able to throw an exception (in the example above as well as in the cancelation call of the library) - functions which must be compiled with exception handling enabled must be identified. These include: + functions which are cancelation points: + functions which use callbacks and those directly or indirectly using functions which use callbacks If things are implemented this way I could argue that the new scheme should be used since it is probably faster than the current implementation. If you can come up with a scheme which works for the case above (I hope I covered all cases) I'd like to learn about it. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gcc-return-9447-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 22:37:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5821 invoked by alias); 24 Aug 1999 22:37:46 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5797 invoked from network); 24 Aug 1999 22:37:44 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 24 Aug 1999 22:37:44 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA23124; Tue, 24 Aug 1999 15:37:40 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id PAA01742; Tue, 24 Aug 1999 15:37:39 -0700 (PDT) Date: Tue, 24 Aug 1999 15:37:39 -0700 (PDT) Message-Id: <199908242237.PAA01742@kankakee.wrs.com> To: gcc@gcc.gnu.org, george@moberg.com, jstern@citilink.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads > Date: Tue, 24 Aug 1999 15:52:44 -0500 (CDT) > From: Josh Stern > To: gcc@gcc.gnu.org, george@moberg.com > If this extension would allow exceptions to be thrown from Unix > signal handlers :-) You can't sneak it in that way. In general, you cannot do this. Specifically, if you read the documentation, and admit that your system is going down in flames, then yes, you might be able to. From gcc-return-9448-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 22:54:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9152 invoked by alias); 24 Aug 1999 22:54:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9105 invoked from network); 24 Aug 1999 22:54:19 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 24 Aug 1999 22:54:19 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990824225418.IWAV20194.mail.rdc1.md.home.com@home.com> for ; Tue, 24 Aug 1999 15:54:18 -0700 Message-ID: <37C32323.B3AABCB5@home.com> Date: Tue, 24 Aug 1999 18:56:35 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: C++ Garbage Collecter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am seriously considering using a garbage collector in one of my C++ projects but before I do I would like to know if there are any problems with egcs/gcc and Garbage collectors that I should know about. In particular will -O2 cause any problems. What about other optimization flags that are not normally included with -O2. I am considering using the Boehm-Demers-Weiser collector (http://reality.sgi.com/employees/boehm_mti/gc.html). Thanks in advance. -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-9449-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 23:23:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13680 invoked by alias); 24 Aug 1999 23:23:36 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13664 invoked from network); 24 Aug 1999 23:23:33 -0000 Received: from johndoe.pdev.sco.com (132.147.193.72) by egcs.cygnus.com with SMTP; 24 Aug 1999 23:23:33 -0000 Received: from sco.com (localhost [127.0.0.1]) by johndoe.pdev.sco.com (8.8.7/UW7.0.1) with ESMTP id QAA01149 for ; Tue, 24 Aug 1999 16:28:01 -0700 (PDT) Message-ID: <37C32A81.F4237C41@sco.com> Date: Tue, 24 Aug 1999 16:28:01 -0700 From: Ronald Joe Record Organization: SCO X-Mailer: Mozilla 4.08 [en] (X11; I; UnixWare 5 i386) MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Build/install GCC 2.95.1 on UnixWare 7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have built and installed GCC 2.95 and 2.95.1 on UnixWare 7. The output of config.guess is i686-UnixWare7.0.1-sysv5 A binary distribution in pkgadd installable format is available via http://www.sco.com/skunkware/uw7/devtools/gcc/ -rr- -- Ronald Joe Record, Open Source Program Architect, The Santa Cruz Operation WWW: http://www.ocston.org/rr http://www.sco.com/skunkware E-mail: rr@sco.com Voice: 831-427-7604 FAX: 831-427-5417 USPS: 400 Encinal Street, Santa Cruz, California 95061 From gcc-return-9450-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 23:24:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13967 invoked by alias); 24 Aug 1999 23:23:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13921 invoked from network); 24 Aug 1999 23:23:55 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 24 Aug 1999 23:23:55 -0000 Received: (qmail 17419 invoked by alias); 24 Aug 1999 23:23:53 -0000 Received: (qmail 17406 invoked from network); 24 Aug 1999 23:23:52 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 24 Aug 1999 23:23:52 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id AAA06753; Wed, 25 Aug 1999 00:23:21 +0100 From: Joern Rennecke Message-Id: <199908242323.AAA06753@phal.cygnus.co.uk> Subject: Re: New const function detection code and infinite loops. In-Reply-To: from Jan Hubicka at "Aug 23, 1999 6:11:14 am" To: jhub6202@ss1000.ms.mff.cuni.cz (Jan Hubicka) Date: Wed, 25 Aug 1999 00:23:21 +0100 (BST) Cc: john@feith.com, egcs@egcs.cygnus.com, law@cygnus.com X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Well and for example following function: > int funct(int b) > { > while(b&1) b+=2; > return b; > } > main() > { > funct(1); > } > despite the fact, that function is complette nonsence, it still contains > infinite loop (for certain input values), but will be marked as const by > the detection code. So this program will terminate. Maybe this is ANSI-C > conforming, but I don't believe so. Since you declared b as int, the result of the overflow is undefined. If you had used 'unsigned int' , the program would be well-defined (to not terminate). From gcc-return-9451-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 23:27:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15396 invoked by alias); 24 Aug 1999 23:27: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15380 invoked from network); 24 Aug 1999 23:27:22 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 24 Aug 1999 23:27:22 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id QAA20638; Tue, 24 Aug 1999 16:26:24 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id QAA18226; Tue, 24 Aug 1999 16:26:24 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id QAA02317; Tue, 24 Aug 1999 16:26:23 -0700 Message-Id: <199908242326.QAA02317@atrus.synopsys.com> Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads To: jstern@citilink.com (Josh Stern) Date: Tue, 24 Aug 99 16:26:23 PDT Cc: jbuck@synopsys.com, jstern@citilink.com, gcc@gcc.gnu.org, george@moberg.com In-Reply-To: <199908242221.RAA10662@foshay.citilink.com>; from "Josh Stern" at Aug 24, 99 5:21 pm X-Mailer: ELM [version 2.3 PL11] My example: > > char * buf = 0; > > try { > > buf = malloc(buf_size); > > } > > catch (SIGNAL) { > > if (buf) > > free(buf); > > } > > > >This code has a race and a leak, and there's no way to write it correctly, > >because the signal could come after malloc has allocated memory but before > >buf is assigned. Josh writes: > I would diagnose the problem above as an inadequate implementation > of malloc() (relative to use in a program that could throw from > a signal handler). No, you are thinking of malloc corruption, which is not the issue here. Assume a perfect implementation, with proper critical regions in malloc (sighold/sigrelease or the like). If buf is in memory -- more likely if I write something like struct_p->buf = malloc(buf_size); there is still a window between the return of malloc (the end of any critical region) and the assignment of the result. Even if buf is a register, we may still need a reg-to-reg move, and the signal could come just before the move. As Mike Stump likes to point out, one still might be able to use async exceptions in particular cases if extreme care is taken. From gcc-return-9452-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 23:29:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16234 invoked by alias); 24 Aug 1999 23:29:20 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16205 invoked from network); 24 Aug 1999 23:29:15 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 24 Aug 1999 23:29:15 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA14839; Tue, 24 Aug 1999 16:29:12 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id QAA12235; Tue, 24 Aug 1999 16:29:12 -0700 To: Josh Stern Cc: jbuck@synopsys.COM, gcc@gcc.gnu.org, george@moberg.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <199908242221.RAA10662@foshay.citilink.com> From: Jason Merrill Date: 24 Aug 1999 16:29:12 -0700 In-Reply-To: Josh Stern's message of "Tue, 24 Aug 1999 17:21:20 -0500 (CDT)" Message-ID: Lines: 41 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Josh Stern writes: > Joe writes: >> Josh writes: >>> If this extension would allow exceptions to be thrown from >>> Unix signal handlers, that would be a very cool feature >>> for even non-threaded programs. >> It wouldn't, since we don't support that in C++ either. The problem >> is that signals can happen anywhere. Consider >> >> char * buf = 0; >> try { >> buf = malloc(buf_size); >> } >> catch (SIGNAL) { >> if (buf) >> free(buf); >> } >> >> This code has a race and a leak, and there's no way to write it correctly, >> because the signal could come after malloc has allocated memory but before >> buf is assigned. > I understand the example, and also (I think) Jason's comment that > asynchronous exceptions are very hard to get right. Just to > pursue this a little bit however... > I would diagnose the problem above as an inadequate implementation > of malloc() (relative to use in a program that could throw from > a signal handler). An acceptable malloc for such a program would > have to catch the SIGNAL exception at a point where it still > had access to the internal data structures that get adjusted > during the memory allocation. Offhand, I don't see why it would > so difficult to write such a malloc. But what if the signal comes in after malloc returns but before the return value is assigned to buf? The problem with asynchronous exceptions is that EVERY INSTRUCTION might throw. Jason From gcc-return-9453-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 24 23:35:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18394 invoked by alias); 24 Aug 1999 23:35:01 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18369 invoked from network); 24 Aug 1999 23:34:59 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 24 Aug 1999 23:34:59 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id QAA20833; Tue, 24 Aug 1999 16:29:28 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id QAA18882; Tue, 24 Aug 1999 16:29:27 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id QAA02362; Tue, 24 Aug 1999 16:29:27 -0700 Message-Id: <199908242329.QAA02362@atrus.synopsys.com> Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads To: mark@codesourcery.com (Mark Mitchell) Date: Tue, 24 Aug 99 16:29:27 PDT Cc: jason@cygnus.com, drepper@cygnus.com, george@moberg.com, kriol@fnal.gov, gcc@gcc.gnu.org, libc-alpha@sourceware.cygnus.com In-Reply-To: <19990824152334N.mitchell@codesourcery.com>; from "Mark Mitchell" at Aug 24, 99 3:23 pm X-Mailer: ELM [version 2.3 PL11] > >> Certainly not. This increase is completely unused in most > >> cases. Mark Mitchell writes: > Since glibc is usually dynamically linked, I don't see why 200K, on > disk, is a big deal at all. One case where it might matter is Linux emergency recovery floppies. A floppy only holds 1.4M (already the Debian folks make a special stripped-down glibc for this purpose, so it might be 100K extra). But since special glibc's are already being made for this purpose, it seems that disabling this mechanism is OK ... unless lots of apps start depending on it. From gcc-return-9454-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 00:08:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25657 invoked by alias); 25 Aug 1999 00:08:02 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25631 invoked from network); 25 Aug 1999 00:07:55 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 25 Aug 1999 00:07:55 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.9.3/8.9.3) with ESMTP id RAA30110; Tue, 24 Aug 1999 17:13:19 -0700 To: jbuck@synopsys.COM Cc: jason@cygnus.com, drepper@cygnus.com, george@moberg.com, kriol@fnal.gov, gcc@gcc.gnu.org, libc-alpha@sourceware.cygnus.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads In-Reply-To: <199908242329.QAA02362@atrus.synopsys.com> References: <19990824152334N.mitchell@codesourcery.com> <199908242329.QAA02362@atrus.synopsys.com> X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990824171319F.mitchell@codesourcery.com> Date: Tue, 24 Aug 1999 17:13:19 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 29 >>>>> "Joe" == Joe Buck writes: >> >> Certainly not. This increase is completely unused in most >> >> cases. Joe> Mark Mitchell writes: >> Since glibc is usually dynamically linked, I don't see why >> 200K, on disk, is a big deal at all. Joe> One case where it might matter is Linux emergency recovery Joe> floppies. A floppy only holds 1.4M (already the Debian folks Joe> make a special stripped-down glibc for this purpose, so it Joe> might be 100K extra). Good point. But, as you say, they're already building a special glibc. I think that only C++/Ada/Java/etc. applications that use exception-handling would need the extra data; obviously, that's a pretty small set or glibc would *already* be built with -fexceptions. There may be systems on which glibc is used, but statically linked. There, I would see more of an issue, as every binary would grow. (For example, this might be true if glibc were ported to a system without shared library support in binutils.) But, I think we should cross that bridge when we come to it. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-9455-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 00:13:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27335 invoked by alias); 25 Aug 1999 00:13:24 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27290 invoked from network); 25 Aug 1999 00:13:23 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 25 Aug 1999 00:13:23 -0000 Received: from otr.mynet (dhcp-sv-0H.cygnus.com [205.180.231.77]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA17626; Tue, 24 Aug 1999 17:13:16 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.9.3/8.9.3/ud-990718) id RAA06237; Tue, 24 Aug 1999 17:10:49 -0700 To: Mark Mitchell Cc: jbuck@synopsys.COM, jason@cygnus.com, george@moberg.com, kriol@fnal.gov, gcc@gcc.gnu.org, libc-alpha@sourceware.cygnus.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <19990824152334N.mitchell@codesourcery.com> <199908242329.QAA02362@atrus.synopsys.com> <19990824171319F.mitchell@codesourcery.com> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Ulrich Drepper Date: 24 Aug 1999 17:10:49 -0700 In-Reply-To: Mark Mitchell's message of "Tue, 24 Aug 1999 17:13:19 -0700" Message-ID: Lines: 15 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Big Bend" Mark Mitchell writes: > Good point. But, as you say, they're already building a special > glibc. I think that only C++/Ada/Java/etc. applications that use > exception-handling would need the extra data; obviously, that's a > pretty small set or glibc would *already* be built with -fexceptions. You can stop discussing this. You gcc guys are not the ones who make the decision. I've described what I will accept and now you can discuss that. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gcc-return-9456-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 00:22:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29639 invoked by alias); 25 Aug 1999 00:22:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29624 invoked from network); 25 Aug 1999 00:22:16 -0000 Received: from smtp6.mindspring.com (207.69.200.74) by egcs.cygnus.com with SMTP; 25 Aug 1999 00:22:16 -0000 Received: from gate.home.bogus (user-38ld6fa.dialup.mindspring.com [209.86.153.234]) by smtp6.mindspring.com (8.8.5/8.8.5) with ESMTP id UAA16687; Tue, 24 Aug 1999 20:22:23 -0400 (EDT) Received: from mindspring.com (bgb.home.bogus [192.168.1.3]) by gate.home.bogus (8.8.4/8.8.4) with ESMTP id UAA11392; Tue, 24 Aug 1999 20:22:12 -0400 Message-ID: <37C33825.CEE48B1@mindspring.com> Date: Tue, 24 Aug 1999 20:26:13 -0400 From: Brian Beuning X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Atkinson CC: gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter References: <37C32323.B3AABCB5@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The main trick will be getting the C++ destructors to run when the GC delete's an object. We used the Boehm collector on my last project and it worked very well for us. Brian Beuning Kevin Atkinson wrote: > I am seriously considering using a garbage collector in one of my C++ > projects but before I do I would like to know if there are any problems > with egcs/gcc and Garbage collectors that I should know about. In > particular will -O2 cause any problems. What about other optimization > flags that are not normally included with -O2. > > I am considering using the Boehm-Demers-Weiser collector > (http://reality.sgi.com/employees/boehm_mti/gc.html). > > Thanks in advance. > -- > Kevin Atkinson > kevinatk@home.com > http://metalab.unc.edu/kevina/ From gcc-return-9457-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 00:28:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30731 invoked by alias); 25 Aug 1999 00:28:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30709 invoked from network); 25 Aug 1999 00:28:41 -0000 Received: from smtp1.cern.ch (137.138.128.38) by egcs.cygnus.com with SMTP; 25 Aug 1999 00:28:41 -0000 Received: from pcep-jamie.cern.ch (pcep-jamie.cern.ch [137.138.38.126]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id CAA02015; Wed, 25 Aug 1999 02:28:35 +0200 (MET DST) Received: (from jamie@localhost) by pcep-jamie.cern.ch (8.9.3/8.9.3) id CAA06918; Wed, 25 Aug 1999 02:28:34 +0200 Date: Wed, 25 Aug 1999 02:28:34 +0200 From: Jamie Lokier To: "George T. Talbot" Cc: Ulrich Drepper , Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Message-ID: <19990825022834.B6865@pcep-jamie.cern.ch> References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> <37C31585.B71A8BA2@moberg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <37C31585.B71A8BA2@moberg.com>; from George T. Talbot on Tue, Aug 24, 1999 at 09:58:29PM +0000 George T. Talbot wrote: > I just had a thought...all I care about is enabling -fexceptions for > any function which is a cancellation point in the C library, or any > function that calls a cancellation point in the C library. Maybe > there's a way to narrow down which functions get -fexceptions applied > to them. I noticed that each function is in its own file, which is a > really good idea and should make that a bit easier. (Does such a list > exist already?) I would think improving the .eh_frame info so that functions without unwind handlers don't take any space in .eh_frame. I.e., some mechanism for "default unwinding" using the frame pointer. Then -fexceptions would be irrelevant to a C library. Exceptions would always work. -- Jamie From gcc-return-9458-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 00:52:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 767 invoked by alias); 25 Aug 1999 00:52:37 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 752 invoked from network); 25 Aug 1999 00:52:34 -0000 Received: from citycenter.citilink.com (root@209.98.8.5) by egcs.cygnus.com with SMTP; 25 Aug 1999 00:52:34 -0000 Received: from foshay.citilink.com (jstern@foshay.citilink.com [209.98.8.9]) by citycenter.citilink.com (8.8.8/8.7.5) with ESMTP id TAA05463; Tue, 24 Aug 1999 19:50:31 -0500 (CDT) Received: (from jstern@localhost) by foshay.citilink.com (8.8.8/8.7.5) id TAA13322; Tue, 24 Aug 1999 19:52:19 -0500 (CDT) Date: Tue, 24 Aug 1999 19:52:19 -0500 (CDT) From: Josh Stern Posted-Date: Tue, 24 Aug 1999 19:52:19 -0500 (CDT) Message-Id: <199908250052.TAA13322@foshay.citilink.com> To: jbuck@synopsys.com, jstern@citilink.com Cc: gcc@gcc.gnu.org, george@moberg.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Josh writes: > I would diagnose the problem above as an inadequate implementation > of malloc() (relative to use in a program that could throw from > a signal handler). >No, you are thinking of malloc corruption, which is not the issue here. >Assume a perfect implementation, with proper critical regions in malloc >(sighold/sigrelease or the like). If buf is in memory -- more likely if >there is still a window between the return of malloc (the end of any >critical region) and the assignment of the result. Even if buf is a >register, we may still need a reg-to-reg move, and the signal could >come just before the move. Of course the chance of getting a signal that you want to throw on just as malloc() returns, combined with the situation where you actually care about the memory leak at this juncture, combined with the situation where the last catch that is released isn't going to just free a whole epoch of allocations, is an extremely low probability circumstance. I understood the example but thought of this case as being lost in the 'noise'. To deal with such a case I would design the malloc in such a way that it assigns the last allocation to a private/static pointer (possibly set up to use per thread storage, if that's relevant) prior to malloc returning, and I would also provide an interface to retrieve this ptr (which is not otherwise used), so that if I am doing a large allocation in a critical program, the the updated version of the exception handler that you wrote eawould retrieve the ptr through the interface and delete it in the case of finding that 'ptr' or 'somestructure->buf' had received a NULL allocation. - Josh From gcc-return-9459-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 01:14:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3766 invoked by alias); 25 Aug 1999 01:14:52 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3751 invoked from network); 25 Aug 1999 01:14:51 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 25 Aug 1999 01:14:51 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA13583; Tue, 24 Aug 1999 18:14:46 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id SAA02810; Tue, 24 Aug 1999 18:14:46 -0700 (PDT) Date: Tue, 24 Aug 1999 18:14:46 -0700 (PDT) Message-Id: <199908250114.SAA02810@kankakee.wrs.com> To: jbuck@synopsys.com, jstern@citilink.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Cc: gcc@gcc.gnu.org, george@moberg.com > Date: Tue, 24 Aug 1999 19:52:19 -0500 (CDT) > From: Josh Stern > Of course the chance of getting a signal that you want to throw on > just as malloc() returns, combined with the situation where you > actually care about the memory leak at this juncture, combined with > the situation where the last catch that is released isn't going to > just free a whole epoch of allocations, is an extremely low > probability circumstance. My guess is that you haven't thought about this long enough to use it. Anyway, doesn't matter what I think... Use the tool to the best of your ability and ask us when it doesn't make sense, and we can clarify any remaining details for you... I just worry that you might expect more to work than will actually work. > I understood the example but thought of this case as being lost in > the 'noise'. See above. From gcc-return-9460-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 02:00:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10218 invoked by alias); 25 Aug 1999 02:00:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10182 invoked from network); 25 Aug 1999 02:00:24 -0000 Received: from edison.dialix.com.au (root@203.12.2.8) by egcs.cygnus.com with SMTP; 25 Aug 1999 02:00:24 -0000 Received: from prophecy.com.au (www.prophecy.com.au [203.12.2.244]) by edison.dialix.com.au (8.9.1/8.9.1/DIALixFlat) with ESMTP id MAA01664 for ; Wed, 25 Aug 1999 12:00:05 +1000 (EST) (envelope-from brendan@dgs.monash.edu.au) Received: from dhcp20.prophecy.com.au ([203.21.127.60] helo=dgs.monash.edu.au) by prophecy.com.au with esmtp (Exim 3.02 #1) id 11JSNM-0000LI-00 for egcs@egcs.cygnus.com; Wed, 25 Aug 1999 12:01:21 +1000 Message-ID: <37C34E7A.7D6A444F@dgs.monash.edu.au> Date: Wed, 25 Aug 1999 12:01:30 +1000 From: Brendan Simon Reply-To: brendan@dgs.monash.edu.au Organization: CTAM Pty Ltd X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: egcs mailing list Subject: debugger formats for C++ code. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I use the SDS SingleStep debugger on a Win32 platform at work. It targets an MPC860 system via the OnCE/BDM port. It seems that SingleStep uses dwarf for debugging and I can debug programs created with GCC if I use the -gdwarf option. However, there is a statement in the SingleStep documentation that says the GNU-CC does not generate dwarf debugging output for C++ code. Is this correct ? If so, is there any reason why it is not supported. We use a C++ compiler (DiabData) all the time as a better C compiler and limiting function scope by using classes. I am trying to convince the company to use GCC and would like to still use SingleStep debugger until Insight is more stable. Is there anyway to get GCC to produce debugging output suitable for the SingleStep compiler. Thanks, Brendan Simon. From gcc-return-9461-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 02:02:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11099 invoked by alias); 25 Aug 1999 02:02:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11067 invoked from network); 25 Aug 1999 02:02:02 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 25 Aug 1999 02:02:02 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990825020159.KUFI20194.mail.rdc1.md.home.com@home.com>; Tue, 24 Aug 1999 19:01:59 -0700 Message-ID: <37C34F21.95D56129@home.com> Date: Tue, 24 Aug 1999 22:04:17 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: Brian Beuning CC: gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter References: <37C32323.B3AABCB5@home.com> <37C33825.CEE48B1@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian Beuning wrote: > We used the Boehm collector on my last project and it worked very > well for us. Does gcc optimizations cause any problems with the garbage collector? -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-9462-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 02:02:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11307 invoked by alias); 25 Aug 1999 02:02:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11243 invoked from network); 25 Aug 1999 02:02:18 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 25 Aug 1999 02:02:18 -0000 Received: from cs.ucla.edu (ts51-9.wla.ts.ucla.edu [164.67.22.182]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id TAA26217; Tue, 24 Aug 1999 19:02:15 -0700 (PDT) Message-ID: <37C34F65.FEC53D54@cs.ucla.edu> Date: Tue, 24 Aug 1999 19:05:25 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Q: porting call_debugger() to g++ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, it's probably not a purely gcc question, but related. As part of our basic libs, I need to port the call_debugger() and the dump_stack() functions. For example, call_debugger() now looks like this void call_debugger() { #if defined(__SUNPRO_CC) || defined(__GNUC__) unsigned ProcId=getpid(); printf("\n --- ATTACHING DEBUGGER to process %d ", ProcId); fflush(stdout); char s[160]; #if defined(__GNUC__) sprintf(s, "gdb -quiet X %d", ProcId); #else sprintf(s, "dbx -q - %d", ProcId); #endif system(s); printf(" ------------------ CONTINUING -------------- \n"); fflush(stdout); #else fprintf(stderr," abk_call_debugger(): Can't call debugger on this platform\n"); fflush(stderr); #endif return; } You can now easily guess how dump_stack() looks. The main problem here is that, unlike dbx, gdb needs to know the name of the executable. In the above code, I just put X as a placeholder. My question is: what's the best way to find the name of the executable? (can assume that the executable is in the curr. directory). Also, I am porting a memory estimation function that used to stat /proc/PID on Solaris. /proc is somewhat different on Linux, so if anyone knows a better way to find out the amount of memory used by the process, I would happily use it. thanks, Igor P.S. It seems that Sun has an edge here with their smarter debugging format.. (just a guess). -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-9463-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 02:22:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17246 invoked by alias); 25 Aug 1999 02:22:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17230 invoked from network); 25 Aug 1999 02:22:05 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 25 Aug 1999 02:22:05 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id UAA02363; Tue, 24 Aug 1999 20:21:08 -0600 X-Mailer: exmh version 2.0.2 To: Kevin Atkinson cc: Brian Beuning , gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 24 Aug 1999 22:04:17 EDT. <37C34F21.95D56129@home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Aug 1999 20:21:07 -0600 Message-ID: <2360.935547667@upchuck.cygnus.com> From: Jeffrey A Law In message <37C34F21.95D56129@home.com>you write: > Brian Beuning wrote: > > > We used the Boehm collector on my last project and it worked very > > well for us. > > Does gcc optimizations cause any problems with the garbage collector? They certainly have the potential to cause problems with garbage collectors. jeff From gcc-return-9464-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 02:43:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19446 invoked by alias); 25 Aug 1999 02:43:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19429 invoked from network); 25 Aug 1999 02:43:12 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 25 Aug 1999 02:43:12 -0000 Received: from localhost (george@localhost) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id WAA31677; Tue, 24 Aug 1999 22:40:52 -0400 Date: Tue, 24 Aug 1999 22:40:52 -0400 (EDT) From: George Talbot To: Jamie Lokier cc: Ulrich Drepper , Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads In-Reply-To: <19990825022834.B6865@pcep-jamie.cern.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 25 Aug 1999, Jamie Lokier wrote: > George T. Talbot wrote: > > I just had a thought...all I care about is enabling -fexceptions for > > any function which is a cancellation point in the C library, or any > > function that calls a cancellation point in the C library. Maybe > > there's a way to narrow down which functions get -fexceptions applied > > to them. I noticed that each function is in its own file, which is a > > really good idea and should make that a bit easier. (Does such a list > > exist already?) > > I would think improving the .eh_frame info so that functions without > unwind handlers don't take any space in .eh_frame. I.e., some mechanism > for "default unwinding" using the frame pointer. > > Then -fexceptions would be irrelevant to a C library. Exceptions would > always work. I would REALLY like to see this. This would mean that it wouldn't really matter whether -fexceptions was on or not, size-wise, so people could leave it on all the time. Anybody know how to do it? -- George T. Talbot From gcc-return-9465-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 02:49:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22158 invoked by alias); 25 Aug 1999 02:49:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22122 invoked from network); 25 Aug 1999 02:49:48 -0000 Received: from smtp.interlog.com (root@207.34.202.37) by egcs.cygnus.com with SMTP; 25 Aug 1999 02:49:48 -0000 Received: from unsworth (209-20-0-155.dialin.interlog.com [209.20.0.155]) by smtp.interlog.com (8.9.1/8.9.1) with SMTP id WAA09051 for ; Tue, 24 Aug 1999 22:49:46 -0400 (EDT) Message-Id: <3.0.6.32.19990824224955.007cb170@mail.interlog.com> X-Sender: gvwilson@mail.interlog.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 24 Aug 1999 22:49:55 -0400 To: gcc@gcc.gnu.org From: Greg Wilson Subject: re: case of G77 symbol tables Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi. I'm trying to call Fortran compiled with g77 from C on Windows NT. When I run 'nm' on the '.obj' produced by g77, it tells me that my function names have all been turned into lower case, i.e. 'setLowThresh' has become 'setlowthresh'. This is causing some of my other tools trouble. Is this case change deliberate? Can it be controlled by a command-line switch? (I couldn't find one in the docs.) Thanks, Greg From gcc-return-9466-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 02:57:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25338 invoked by alias); 25 Aug 1999 02:57: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25307 invoked from network); 25 Aug 1999 02:57:23 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 25 Aug 1999 02:57:23 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id TAA26747; Tue, 24 Aug 1999 19:57:12 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id TAA12424; Tue, 24 Aug 1999 19:57:12 -0700 To: Jamie Lokier Cc: "George T. Talbot" , Ulrich Drepper , Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> <37C31585.B71A8BA2@moberg.com> <19990825022834.B6865@pcep-jamie.cern.ch> From: Jason Merrill Date: 24 Aug 1999 19:57:12 -0700 In-Reply-To: Jamie Lokier's message of "Wed, 25 Aug 1999 02:28:34 +0200" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Jamie Lokier writes: > I would think improving the .eh_frame info so that functions without > unwind handlers don't take any space in .eh_frame. I.e., some mechanism > for "default unwinding" using the frame pointer. .eh_frame has nothing to do with how many handlers a function has; it tells the unwinder how to reload the registers saved in the function prologue so that they have the right values when we get to a handler in the caller. It is possible to do unwinding without .eh_frame; gdb does it by disassembling the prologue, but this doesn't always work. Another possiblity would be to declare that all registers are clobbered on entry to an exception handler; then the default unwinder would only have to worry about how to find the return address and saved stack pointer for a frame, which is usually straightforward if you have a frame pointer to work with. Jason From gcc-return-9467-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 03:00:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26508 invoked by alias); 25 Aug 1999 03:00:24 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26493 invoked from network); 25 Aug 1999 03:00:24 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 25 Aug 1999 03:00:24 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id UAA26923; Tue, 24 Aug 1999 20:00:23 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id UAA12427; Tue, 24 Aug 1999 20:00:23 -0700 To: brendan@dgs.monash.edu.au Cc: egcs mailing list Subject: Re: debugger formats for C++ code. References: <37C34E7A.7D6A444F@dgs.monash.edu.au> From: Jason Merrill Date: 24 Aug 1999 20:00:23 -0700 In-Reply-To: Brendan Simon's message of "Wed, 25 Aug 1999 12:01:30 +1000" Message-ID: Lines: 16 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Brendan Simon writes: > I use the SDS SingleStep debugger on a Win32 platform at work. It > targets an MPC860 system via the OnCE/BDM port. It seems that > SingleStep uses dwarf for debugging and I can debug programs created > with GCC if I use the -gdwarf option. However, there is a statement in > the SingleStep documentation that says the GNU-CC does not generate > dwarf debugging output for C++ code. Is this correct ? If so, is there > any reason why it is not supported. Because DWARF version 1 does not support C++ very well. We generate incomplete information, but if you want reasonable debugging output, you need to use stabs or dwarf v2. The Diab compiler may use some extensions to dwarf v1 to make it more suitable; several vendors do, but we don't. Jason From gcc-return-9468-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 03:15:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28882 invoked by alias); 25 Aug 1999 03:15:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28862 invoked from network); 25 Aug 1999 03:15:06 -0000 Received: from citycenter.citilink.com (root@209.98.8.5) by egcs.cygnus.com with SMTP; 25 Aug 1999 03:15:06 -0000 Received: from foshay.citilink.com (jstern@foshay.citilink.com [209.98.8.9]) by citycenter.citilink.com (8.8.8/8.7.5) with ESMTP id WAA15520 for ; Tue, 24 Aug 1999 22:13:08 -0500 (CDT) Received: (from jstern@localhost) by foshay.citilink.com (8.8.8/8.7.5) id WAA15685 for gcc@gcc.gnu.org; Tue, 24 Aug 1999 22:14:56 -0500 (CDT) Date: Tue, 24 Aug 1999 22:14:56 -0500 (CDT) From: Josh Stern Posted-Date: Tue, 24 Aug 1999 22:14:56 -0500 (CDT) Message-Id: <199908250314.WAA15685@foshay.citilink.com> To: gcc@gcc.gnu.org Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Mike Stump writes: >I just worry that you might expect more to work than will actually >work. I won't question the sincerity of your worry...for all I know you might (or perhaps should) have shared it with the C++ committee. However, just to clarify my view: I would expect try (sic) to handle even synchronous exceptions either very locally or very globally, with very constrained ambitions in the latter case (which, of course, anything involving a signal handler would fall into). I don't mean to disrespect the *extremely* hard work that has been put into some other programming idioms that place a lot of value on exception safety of classes, etc., though I have some doubts about whether those approaches can be adequately tested and/or make it easy for programmers to be productive. - Josh From gcc-return-9469-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 03:16:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29429 invoked by alias); 25 Aug 1999 03:15:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29389 invoked from network); 25 Aug 1999 03:15:56 -0000 Received: from smtp6.mindspring.com (207.69.200.74) by egcs.cygnus.com with SMTP; 25 Aug 1999 03:15:56 -0000 Received: from gate.home.bogus (user-38ld6fa.dialup.mindspring.com [209.86.153.234]) by smtp6.mindspring.com (8.8.5/8.8.5) with ESMTP id XAA22692; Tue, 24 Aug 1999 23:16:01 -0400 (EDT) Received: from mindspring.com (bgb.home.bogus [192.168.1.3]) by gate.home.bogus (8.8.4/8.8.4) with ESMTP id XAA12345; Tue, 24 Aug 1999 23:15:40 -0400 Message-ID: <37C360C0.46D76D79@mindspring.com> Date: Tue, 24 Aug 1999 23:19:36 -0400 From: Brian Beuning X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Atkinson CC: gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter References: <37C32323.B3AABCB5@home.com> <37C33825.CEE48B1@mindspring.com> <37C34F21.95D56129@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit That project used the MIPS native compiler (not gcc) which has a fairly agressive optimizer. We never had a problem with the GC and optimzer not getting along. In case you are not familair with it, the Boehm GC is a "conservative" GC which means it scans all registers, stack space, heap space, and global memory looking for objects that might be pointers. When it finds 4 bytes that could be a pointer it considers the object it points to as "in use" and will not collect it. There are a couple of coding techniques that can cause trouble. 1. Only storing (only) a pointer to an object that is outside the object, for example char * alloc() { char * x = (char *) malloc( 100 ); return x-10; } then the calling code knows to add 10 before using it. This is highly perverse code and not likely to be found in practice, but it would break the Boehm GC. 2. There is a clever trick for saving a pointer in a double linked list by storing (only) the XOR of the forward and backward pointers in the current list item. The Boehm GC might not see any references to the list items and free the list items when they are really in use. Again this is perverse code. If I remember right, the GC documentation mentions a few optimizer issues but there were not many. Below is the main reference to check out. Brian Beuning Possible interactions between the collector and optimizing compilers are discussed in Boehm, H., and D. Chase, "A Proposal for GC-safe C Compilation", The Journal of C Language Translation 4, 2 (December 1992). and Boehm H., "Simple GC-safe Compilation", Proceedings of the ACM SIGPLAN '96 Conference on Programming Language Design and Implementation. (Both are also available from http://reality.sgi.com/employees/boehm_mti/papers/, among other places.) Kevin Atkinson wrote: > Brian Beuning wrote: > > > We used the Boehm collector on my last project and it worked very > > well for us. > > Does gcc optimizations cause any problems with the garbage collector? > -- > Kevin Atkinson > kevinatk@home.com > http://metalab.unc.edu/kevina/ From gcc-return-9470-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 03:29:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31591 invoked by alias); 25 Aug 1999 03:29:16 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31574 invoked from network); 25 Aug 1999 03:29:12 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 25 Aug 1999 03:29:12 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id VAA02740; Tue, 24 Aug 1999 21:28:19 -0600 X-Mailer: exmh version 2.0.2 To: Brian Beuning cc: Kevin Atkinson , gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 24 Aug 1999 23:19:36 EDT. <37C360C0.46D76D79@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Aug 1999 21:28:13 -0600 Message-ID: <2737.935551693@upchuck.cygnus.com> From: Jeffrey A Law In message <37C360C0.46D76D79@mindspring.com>you write: > That project used the MIPS native compiler (not gcc) which has > a fairly agressive optimizer. We never had a problem with the > GC and optimzer not getting along. But that does not mean you will not run into such problems. As a compiler junkie, I *know* GCC will create situations which will spoof a garbage collector. > There are a couple of coding techniques that can cause trouble. > 1. Only storing (only) a pointer to an object that is outside the object, > > for example > char * alloc() { > char * x = (char *) malloc( 100 ); > return x-10; > } > then the calling code knows to add 10 before using it. This is highly > perverse code and not likely to be found in practice, but it would break > the Boehm GC. Actually, compilers do this internally sometimes as it allows them to generate more efficient loop code. jeff From gcc-return-9471-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 04:02:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2407 invoked by alias); 25 Aug 1999 04:02:06 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2383 invoked from network); 25 Aug 1999 04:01:53 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 25 Aug 1999 04:01:53 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990825040151.LWBG20194.mail.rdc1.md.home.com@home.com>; Tue, 24 Aug 1999 21:01:51 -0700 Message-ID: <37C36B3B.DDAD6A0E@home.com> Date: Wed, 25 Aug 1999 00:04:11 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: law@cygnus.com CC: Brian Beuning , gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter References: <2360.935547667@upchuck.cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeffrey A Law wrote: > > In message <37C34F21.95D56129@home.com>you write: > > Brian Beuning wrote: > > > > > We used the Boehm collector on my last project and it worked very > > > well for us. > > > > Does gcc optimizations cause any problems with the garbage collector? > They certainly have the potential to cause problems with garbage collectors. Then I guess the question is: Does anyone have any plans on making gcc garbage collector safe? -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-9472-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 04:10:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3786 invoked by alias); 25 Aug 1999 04:10:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3763 invoked from network); 25 Aug 1999 04:10:09 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 25 Aug 1999 04:10:09 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id WAA02896; Tue, 24 Aug 1999 22:09:11 -0600 X-Mailer: exmh version 2.0.2 To: Kevin Atkinson cc: Brian Beuning , gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 25 Aug 1999 00:04:11 EDT. <37C36B3B.DDAD6A0E@home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Aug 1999 22:09:11 -0600 Message-ID: <2893.935554151@upchuck.cygnus.com> From: Jeffrey A Law In message <37C36B3B.DDAD6A0E@home.com>you write: > Then I guess the question is: Does anyone have any plans on making gcc > garbage collector safe? Yes, but no specifics yet. This is driven by the ultimate desire to be able to hook in a garbage collector into gcc itself. jeff From gcc-return-9473-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 04:56:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10435 invoked by alias); 25 Aug 1999 04:56:40 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10410 invoked from network); 25 Aug 1999 04:56:36 -0000 Received: from garfield.dis.com (199.4.97.30) by egcs.cygnus.com with SMTP; 25 Aug 1999 04:56:36 -0000 Received: from garfield (199.4.97.30) by garfield.dis.com (EMWAC SMTPRS 0.81) with SMTP id ; Tue, 24 Aug 1999 21:56:33 -0700 Message-Id: <4.1.19990824214047.00ce42e0@garfield.dis.com> X-Sender: mark@garfield.dis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 24 Aug 1999 21:56:31 -0700 To: law@cygnus.com From: Mark Klein Subject: Re: HARD_REGNO_MODE_OK on PA-RISC (revisited) Cc: gcc@gcc.gnu.org In-Reply-To: <2443.935548630@upchuck.cygnus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 08:37 PM 8/24/99 -0600, Jeffrey A Law wrote: >There is nothing wrong with requiring aligned registers, it is just suboptimal. The original question had to do with long double which according to the ACD must be aligned on a 128 bit boundary. This is what works for long double. If I'm missing something else, please refresh my memory, as it has been over four months since I looked at this. /* * Value is 1 if hard register REGNO can hold a value of machine-mode MODE. * 32 bit reg/subreg can fit in any general register. On PA1.0, FP regs * are 64 bits wide, but 32 bit quantities must be in the leftmost 32 * bits of the FP register. On PA1.1, FP regs are still 64 bits wide, * but both halves can contain 32 bit quantities. In gcc, these registers * are each treated as a separate 32 bit FP register. So, modes greater * than 32 bits must be aligned on "even" registers. 128 bit floating * point must be aligned in evenly aligned FP registers on PA 1.0 and * because of the remapping for PA1.1, registers evenly divisible by 4. * For PA 1.0, disallow wide non-floating point modes in FP registers. */ #define HARD_REGNO_MODE_OK(REGNO, MODE) \ ((REGNO) == 0 \ ? (MODE) == CCmode || (MODE) == CCFPmode \ : FP_REGNO_P (REGNO) \ ? !TARGET_PA_11 \ ? GET_MODE_SIZE (MODE) <= 4 || \ GET_MODE_CLASS (MODE) == MODE_FLOAT && \ (GET_MODE_SIZE (MODE) <= 8 && ((REGNO) & 1) == 0 || \ ((REGNO) & 3) == 0) \ : GET_MODE_SIZE (MODE) <= 4 || \ (GET_MODE_SIZE (MODE) <= 8 && ((REGNO) & 1) == 0) || \ ((REGNO) & 3) == 0 \ : 1) -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available From gcc-return-9474-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 05:03:23 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13189 invoked by alias); 25 Aug 1999 05:03:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13171 invoked from network); 25 Aug 1999 05:03:19 -0000 Received: from adsl-216-102-199-253.dsl.snfc21.pacbell.net (HELO magnus.bothner.com) (root@216.102.199.253) by egcs.cygnus.com with SMTP; 25 Aug 1999 05:03:19 -0000 Received: by bothner.com via sendmail from stdin id (Debian Smail3.2.0.102) for gcc@gcc.gnu.org; Tue, 24 Aug 1999 22:09:24 -0700 (PDT) To: gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter References: <2737.935551693@upchuck.cygnus.com> From: Per Bothner Date: 24 Aug 1999 22:09:24 -0700 In-Reply-To: Jeffrey A Law's message of "Tue, 24 Aug 1999 21:28:13 -0600" Message-ID: Lines: 61 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta14) (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Jeffrey A Law writes: > > There are a couple of coding techniques that can cause trouble. > > 1. Only storing (only) a pointer to an object that is outside the object, > > > > for example > > char * alloc() { > > char * x = (char *) malloc( 100 ); > > return x-10; > > } > > then the calling code knows to add 10 before using it. This is highly > > perverse code and not likely to be found in practice, but it would break > > the Boehm GC. > Actually, compilers do this internally sometimes as it allows them to > generate more efficient loop code. I don't think these statements are very relevant. Yes, the compiler sometimes does such re-writing, but that is not a problem for a conservative collectors as long as there is still a pointer somewhere that points to the actual base of the object. And either you have a newly allocated object that will be passed to someone, or it was an existing object that was passed from somewhere (as an argument). In either case, you would have a pointer to the base object somewhere. There is one problem I can think of: Allocating a temporary object is only used *local* to a function: char *x = (char*) gcmalloc(100); ... do stuff with x ... /* at this point x is dead */ Here you are the risk that x might be prematurely collected. The work-around is easy: Don't do that. Instead, use non gc-managed memory for objects only used internally in a single function: class malloced { void *p; malloced(void *ptr) { p = ptr; } ~malloced() { free(p); } } char *x = (char*) malloc(100); malloced(x); ... do stuff with x ... /* malloced's finalizer will free x. */ There is at least one example of this "bad" use of gc'd memory in libgjc, in the calls to _Jv_AllocBytes in java/lang/natSystem.cc. I argued against using gc'd memory for such buffers, mainly as a matter of style. But I think we here have another reason to avoid it. (In the case at hand in natSystem.cc, I think we are safe, because the buffer is passed as an argument to getpwuid_r, and there is no arithmetic on the pointer.) In practice, you are much more likely to get hosed by other problems (including compiler bugs) than having the optimizer screw up conservative collection. It is a theoretical problem, but my impression is that it is not an issue in practice. -- --Per Bothner bothner@pacbell.net per@bothner.com http://home.pacbell.net/bothner/ From gcc-return-9475-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 05:39:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18393 invoked by alias); 25 Aug 1999 05:39:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18364 invoked from network); 25 Aug 1999 05:38:58 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 25 Aug 1999 05:38:58 -0000 Received: (qmail 24657 invoked by alias); 25 Aug 1999 05:38:56 -0000 Received: (qmail 24652 invoked from network); 25 Aug 1999 05:38:55 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 25 Aug 1999 05:38:55 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id GAA07188; Wed, 25 Aug 1999 06:38:23 +0100 From: Joern Rennecke Message-Id: <199908250538.GAA07188@phal.cygnus.co.uk> Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads In-Reply-To: from Ulrich Drepper at "Aug 24, 1999 3:33:56 pm" To: drepper@cygnus.com Date: Wed, 25 Aug 1999 06:38:23 +0100 (BST) Cc: george@moberg.com, kriol@fnal.gov, gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > + functions which use callbacks and those directly or indirectly using > functions which use callbacks This can be automated. Hack gcc so that it logs function and file name when code is compiled that dereferences a function pointer, and compile glibc with this hacked gcc. This gives you the functions that use callbacks. Than you search for functions that use these functions, and in turn for functions that use those functions, till no new functions are found. From gcc-return-9476-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 05:43:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19779 invoked by alias); 25 Aug 1999 05:43:07 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19764 invoked from network); 25 Aug 1999 05:43:05 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 25 Aug 1999 05:43:05 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990825054304.MNJS20194.mail.rdc1.md.home.com@home.com>; Tue, 24 Aug 1999 22:43:04 -0700 Message-ID: <37C382F4.39E791CD@home.com> Date: Wed, 25 Aug 1999 01:45:24 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: Per Bothner CC: gcc@gcc.gnu.org Subject: Bad C++ code (was Re: C++ Garbage Collecter) References: <2737.935551693@upchuck.cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Per Bothner wrote: have a pointer to the base object somewhere. > > There is one problem I can think of: Allocating a temporary object > is only used *local* to a function: > > char *x = (char*) gcmalloc(100); > ... do stuff with x ... > /* at this point x is dead */ > > Here you are the risk that x might be prematurely collected. The > work-around is easy: Don't do that. Instead, use non gc-managed > memory for objects only used internally in a single function: > > class malloced { > void *p; > malloced(void *ptr) { p = ptr; } > ~malloced() { free(p); } > } > > char *x = (char*) malloc(100); > malloced(x); except that malloced(x) will be deleted here (before the next line) What you wanted to say was malloced x0 = x; > ... do stuff with x ... > /* malloced's finalizer will free x. */ -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-9477-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 05:45:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20916 invoked by alias); 25 Aug 1999 05:45:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20817 invoked from network); 25 Aug 1999 05:45:10 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 25 Aug 1999 05:45:10 -0000 Received: (qmail 24915 invoked by alias); 25 Aug 1999 05:45:05 -0000 Received: (qmail 24904 invoked from network); 25 Aug 1999 05:45:04 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 25 Aug 1999 05:45:04 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id GAA07206; Wed, 25 Aug 1999 06:44:32 +0100 From: Joern Rennecke Message-Id: <199908250544.GAA07206@phal.cygnus.co.uk> Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads In-Reply-To: <19990824171319F.mitchell@codesourcery.com> from Mark Mitchell at "Aug 24, 1999 5:13:19 pm" To: mark@codesourcery.com (Mark Mitchell) Date: Wed, 25 Aug 1999 06:44:31 +0100 (BST) Cc: jbuck@synopsys.COM, jason@cygnus.com, drepper@cygnus.com, george@moberg.com, kriol@fnal.gov, gcc@gcc.gnu.org, libc-alpha@sourceware.cygnus.com X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > There may be systems on which glibc is used, but statically linked. > There, I would see more of an issue, as every binary would grow. (For > example, this might be true if glibc were ported to a system without > shared library support in binutils.) But, I think we should cross > that bridge when we come to it. This could be solved by stripping the exception information if a program is linked wherenoneof the non-library object files have exception information. Then anordinary C program should get nosize increase. From gcc-return-9478-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 06:05:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26198 invoked by alias); 25 Aug 1999 06:05:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26175 invoked from network); 25 Aug 1999 06:05:21 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 25 Aug 1999 06:05:21 -0000 Received: from otr.mynet (dialin-sv-02.cygnus.com [205.180.231.52]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id XAA04227; Tue, 24 Aug 1999 23:05:15 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.9.3/8.9.3/ud-990718) id XAA06775; Tue, 24 Aug 1999 23:02:47 -0700 To: Joern Rennecke Cc: george@moberg.com, kriol@fnal.gov, gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <199908250538.GAA07188@phal.cygnus.co.uk> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Ulrich Drepper Date: 24 Aug 1999 23:02:47 -0700 In-Reply-To: Joern Rennecke's message of "Wed, 25 Aug 1999 06:38:23 +0100 (BST)" Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Big Bend" Joern Rennecke writes: > This can be automated. No, it cannot. There is sometimes asm() code ein functions doing callbacks. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gcc-return-9479-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 06:19:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28898 invoked by alias); 25 Aug 1999 06:19: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28880 invoked from network); 25 Aug 1999 06:19:23 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 25 Aug 1999 06:19:23 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.9.3/8.9.3) with ESMTP id XAA30398; Tue, 24 Aug 1999 23:24:13 -0700 To: drepper@cygnus.com Cc: amylaar@cygnus.co.uk, george@moberg.com, kriol@fnal.gov, gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads In-Reply-To: References: <199908250538.GAA07188@phal.cygnus.co.uk> X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990824232413R.mitchell@codesourcery.com> Date: Tue, 24 Aug 1999 23:24:13 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 16 >>>>> "Ulrich" == Ulrich Drepper writes: Ulrich> Joern Rennecke writes: >> This can be automated. Ulrich> No, it cannot. There is sometimes asm() code ein Ulrich> functions doing callbacks. And, in any case, doing the process once isn't enough. It really would need to be done every time glibc is built, to make sure that no change would require more functions to have EH support. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-9480-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 06:50:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2863 invoked by alias); 25 Aug 1999 06:49:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2797 invoked from network); 25 Aug 1999 06:49:31 -0000 Received: from thor.xraylith.wisc.edu (198.150.6.11) by egcs.cygnus.com with SMTP; 25 Aug 1999 06:49:30 -0000 Received: from mercury.xraylith.wisc.edu (mercury.xraylith.wisc.edu [128.104.182.221]) by thor.xraylith.wisc.edu (8.9.1a/8.9.1) with ESMTP id BAA07940 for ; Wed, 25 Aug 1999 01:49:27 -0500 Received: from mercury.xraylith.wisc.edu (localhost [127.0.0.1]) by mercury.xraylith.wisc.edu (8.8.7/8.8.7) with ESMTP id BAA22183 for ; Wed, 25 Aug 1999 01:49:03 -0500 Message-Id: <199908250649.BAA22183@mercury.xraylith.wisc.edu> To: gcc@gcc.gnu.org Subject: (fwd) G77 2.95 performance increase for x86-win32 Date: Wed, 25 Aug 1999 01:49:03 -0500 From: Mumit Khan Good part of the credit goes to the better alignment on x86. Too bad my own code doesn't get as much of a boost ;-) ------- Forwarded Message Date: Wed, 25 Aug 1999 10:00:18 +0900 From: "Kan, Masahiro" Subject: GCC-2.95 for Mingw32 Dear Dr. Mumit Khan, As I wrote before, we are using Mingw32 compiler for ATP(Alternative Transients Program)-EMTP(Electro Magnetic Transients Program). This has been good, and this time, GCC-2.95 for mingw32 which you published made a significant improvement for this program. I appreciate your work very much and forward a message of Dr. Scott Meyer of the Bonneville Power Administration who is the author of this program. --------- Forwarded Message [snip] .... the third of these documents improved simulation speed using DC-1: -------------------------------------------- Data in Phasor pre-dT dT loop Total -------------------------------------------- Old: 1.091 .351 .370 7.161 9.063 New: .751 .090 .091 6.029 6.980 ----------------------------------------------------- [snip] If these numbers stand up to repeated, detailed scrutiny, it would appear that need for Watcom ATP might finally have vanished. You should be very happy. This new compiler seems to be very important news. If you know whom it came from, we encourage you to pass along our compliments and appreciation. --------- End of Forwarded Message ----------------------------------- Masahiro Kan Toshiba Corporation, Japan E-MAIL:"Masahiro Kan at Toshiba" "Masahiro Kan at Home" WWW(ATP-EMTP-jp) : http://www02.so-net.or.jp/~m_kan/index-e.htm ------- End of Forwarded Message From gcc-return-9481-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 08:06:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25236 invoked by alias); 25 Aug 1999 08:06:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25221 invoked from network); 25 Aug 1999 08:06:18 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 25 Aug 1999 08:06:18 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id CAA04187; Wed, 25 Aug 1999 02:05:11 -0600 X-Mailer: exmh version 2.0.2 To: Antony T Curtis cc: gcc@gcc.gnu.org Subject: Re: Successful build of egcs 1.1.2 on AIX 4.3.2.0 Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 27 Jul 1999 17:44:26 BST. <379DE1EA.C45CD4E4@abacus.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Aug 1999 02:05:11 -0600 Message-ID: <4184.935568311@upchuck.cygnus.com> From: Jeffrey A Law In message <379DE1EA.C45CD4E4@abacus.co.uk>you write: > > egcs 1.1.2 built successfully on AIX 4.3.2.0 > > Only modification: In gcc/config/rs6000/rs6000.h, changed MY_ISCOFF > definition to > > #define MY_ISCOFF(magic) \ > ( (magic) == U803XTOCMAGIC || (magic) == U803TOCMAGIC \ > || (magic) == U802TOCMAGIC || (magic) == U802WRMAGIC \ > || (magic) == U802ROMAGIC ) > > This enabled it to build successfully on: gcc-2.95 has equivalent code. So it should work out of the box. Thanks for your patch/report. jeff From gcc-return-9482-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 09:24:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4417 invoked by alias); 25 Aug 1999 09:24:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4396 invoked from network); 25 Aug 1999 09:24:53 -0000 Received: from bubble.ndsuk.com (194.216.129.248) by egcs.cygnus.com with SMTP; 25 Aug 1999 09:24:53 -0000 Received: from SMTP (emma.hedge.ndsuk.com [172.17.253.25]) by bubble.ndsuk.com (8.8.7/8.8.7) with SMTP id JAA05613; Wed, 25 Aug 1999 09:23:43 GMT Received: from sage.hedge.ndsuk.com ([172.17.253.10]) by 172.17.253.25 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 25 Aug 1999 09:17:37 0000 (GMT) Received: from ibm.net (ndsuk4908.stone.ndsuk.com [172.16.195.75]) by sage.hedge.ndsuk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id RQDA6G0L; Wed, 25 Aug 1999 10:23:40 +0100 Message-ID: <37C3B61C.3F71EF42@ibm.net> Date: Wed, 25 Aug 1999 10:23:40 +0100 From: Etienne Lorrain Organization: Protection of the "jnp" instruction league X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "H.J. Lu" , Alan Modra , Ian Lance Taylor CC: egcs@egcs.cygnus.com Subject: Re: binutils 2.9.5.0.8 is released. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, > Please report any bugs related to binutils 2.9.5.0.8 to hjl@lucon.org. No more problem for me, it is assembling correctly all my real mode stuff, and the linker is correct. I have written previously, and I was wrong, this extract: > I noticed a feature with my software (gujin) on the linker side. > This exists on RH 6 version of binutils and your lattest snapshot, > but was not present on standart RH 5 distributions (early binutils-2.9.1). > > Simply, it is a gap of 0x10 bytes out of sections, i.e. in between > .code and .data - and it seems to be unvolumtary (i.e. no alignment > needed because it is already aligned). I did not understand then that sections (.code, .data) are now aligned to 0x20 (i.e. 32 bytes) with the new linker - instead of 0x10 - and so my "out of section" gap was just an alignment stuff. I hope to have this binutils in major distributions soon! Thanks, Etienne. Note to EGCS list: this message does not mean that "attribute ((packed))" on variables (more precisely complex structure) is working as documented in any version of gcc/EGCS since EGCS-1.1 ... From gcc-return-9483-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 10:59:17 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16577 invoked by alias); 25 Aug 1999 10:59:16 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16562 invoked from network); 25 Aug 1999 10:59:14 -0000 Received: from h207-21-174-99.ncal.verio.net (HELO spell.bitmicro.com) (207.21.174.99) by egcs.cygnus.com with SMTP; 25 Aug 1999 10:59:14 -0000 Received: from pseri.boup.marx.co.se ([209.150.128.88]) by spell.bitmicro.com (Post.Office MTA v3.5.2 release 221 ID# 0-57439U100L100S0V35) with SMTP id com; Mon, 25 Jan 1999 22:46:41 -0800 From: nnzic@boup.marx.co.se To: ppzqv@fraxe.mots.com.il Reply-To: Subject: Please Reply ASAP! [jfdbv] $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ WANTED: Motivated Leaders Looking For The Right Opportunity To Make It Big! This one REALLY DOES PAY! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$2 This is a LEGITIMATE International Opportunity to earn a Large Residual Income in the Shortest Period of Time. Not Like Other Opportunities That Drain Your Savings & Don't Work. $500 Front End Bonuses Paid the Next Day! Unheard of Back End Residual Income Paid Weekly & Monthly! Start Earning $$ Cash $$ Your First Week! Team Support, Website for only $9.95 and Valuable Marketing Training! No Selling or Purchases of Products Required… Just a Simple and Duplicatable System !!! Anyone Can Duplicate This! This opportunity is extremely powerful and truly the "Opportunity of a lifetime." You owe it to yourself to take a look. --------------------------------------------------------- See What Others Are Saying: I joined and sponsored 6 people and was paid $1000 in 3 weeks. Since then my group has grown to over 120 in just a few weeks. Never have I experienced this kind of growth in networking. Not to mention the money I am receiving weekly. M.B. It usually takes me 6 months to build a business over $1000 per month, but with this program it took just weeks. Wow, I'm impressed. J.S. In less than 6 months I'm earning over $4000+ per month. It's easy but takes action. If you build it, this company pays well. Ordinary people who have tried everything and failed, are now using this breakthrough fast cash system to effortlessly go from past financial failure to extraordinary wealth in a short period of time. B.B. For More Information, reply with "fastandeasycash" on the Subject line. mailto:p22m@bigfoot.com?subject=fastandeasycash Or you may Fax your reply to 603-909-5958 with your Email address and the words "fastandeasycash." Have a Great Day! From gcc-return-9484-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 11:26:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23790 invoked by alias); 25 Aug 1999 11:26:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23706 invoked from network); 25 Aug 1999 11:25:56 -0000 Received: from sasi.com (164.164.56.2) by egcs.cygnus.com with SMTP; 25 Aug 1999 11:25:56 -0000 Received: from suna13.nt.sasi.com (suna13.nt.sasi.com [202.21.147.13]) by sasi.com (8.9.0/8.9.0) with ESMTP id RAA03296 for ; Wed, 25 Aug 1999 17:00:41 +0530 Received: from suna19.nt.sasi.com (suna19.nt.sasi.com [202.21.147.19]) by suna13.nt.sasi.com (8.8.7/8.8.8) with ESMTP id QAA04048 for ; Wed, 25 Aug 1999 16:54:03 +0530 (IST) Received: from sasi.com (lnxa109.nt.sasi.com [202.21.147.109]) by suna19.nt.sasi.com (8.9.1/8.9.1) with ESMTP id RAA19697 for ; Wed, 25 Aug 1999 17:03:35 +0530 (IST) Message-ID: <37C3D48C.2CA09F93@sasi.com> Date: Wed, 25 Aug 1999 17:03:33 +0530 From: sanjeev Reply-To: sanjeev@sasi.com Organization: SAS X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: SUBSCRIBE TO MAILING LIST Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From gcc-return-9485-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 11:54:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29518 invoked by alias); 25 Aug 1999 11:54:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29495 invoked from network); 25 Aug 1999 11:54:14 -0000 Received: from smtp.interlog.com (root@207.34.202.37) by egcs.cygnus.com with SMTP; 25 Aug 1999 11:54:14 -0000 Received: from crjnt2 (cj.interlog.com [199.212.157.174]) by smtp.interlog.com (8.9.1/8.9.1) with SMTP id HAA03227 for ; Wed, 25 Aug 1999 07:54:06 -0400 (EDT) Message-Id: <3.0.32.19990825075547.009b3930@mail.interlog.com> X-Sender: cj@mail.interlog.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 25 Aug 1999 07:55:48 -0400 To: gcc@gcc.gnu.org From: "Christopher R. Jones" Subject: Re: Strange behaviour in C++... Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am puzzled at the lack of attention this thread has received. There is obviously some strange behavior with gcc 2.95.1 on Linux (at least Redhat 5.2): Using a 180 Pentium Pro: >From Solairs Intel, gcc 2.95.1, built with gcc 2.8: Alfa 1=3D42 Alfa 2=3D42 BetaAlfa=3D42 Alfa 1=3D47 Alfa 2=3D47 GammaAlfa=3D47 AlfaGammaAlfa=3D47 >From Linux Redhat 5.2, gcc 2.95.1, built with egcs 1.1.2: Alfa 1=3D42 Alfa 2=3D42 BetaAlfa=3D42 Alfa 1=3D47 Alfa 2=3D134580833 GammaAlfa=3D47 AlfaGammaAlfa=3D47 At 04:54 PM 8/24/99 +0200, Fredrik =D6hrstr=F6m wrote: > >The code below compiled with 2.95.1 (19990816)=20 >(on a RedHat 5.2 system i386) produces: > >Alfa 1=3D42 >Alfa 2=3D42 >BetaAlfa=3D42 >Alfa 1=3D47 >Alfa 2=3D134580865 >GammaAlfa=3D47 >AlfaGammaAlfa=3D47 > >Shouldn't Alfa 2 be 47 in the second creation? > >Cheers >Fredrik > >--------------------------------------------------------- > > >#include > >struct Alfa >{ > virtual int alfa() =3D 0; >}; > >struct Beta >{}; > >struct Gamma >{}; > >struct Alfa_i : public virtual Alfa =20 >{ > int a; > > Alfa_i (int aa) : a (aa) > { > } =20 > =20 > int alfa () > { > return a; > } >}; > >struct Beta_i : public virtual Beta, > public Alfa_i >{ > Beta_i (int bb) : Alfa_i (bb) > { > cerr << "Alfa 1=3D" << alfa ()<< endl; > Alfa *a =3D this; > cerr << "Alfa 2=3D" << a->alfa ()<< endl; =20 > } >}; > >struct Gamma_i : public virtual Gamma, > public Beta_i >{ > Gamma_i (int cc)=20 > : Beta_i (cc) > {} >}; > > =20 >int main () >{ > Beta_i *b =3D new Beta_i (42); > cerr << "BetaAlfa=3D" << b->alfa() << endl; > > Gamma_i *g =3D new Gamma_i (47); > cerr << "GammaAlfa=3D" << g->alfa() << endl; > > Alfa *a =3D g; > cerr << "AlfaGammaAlfa=3D" << a->alfa() << endl; =20 >} > > > > > Christopher R. Jones, P.Eng. 14 Oneida Avenue Toronto, Ontario M5J 2E3 Tel. 416 203-7465 Fax. 416 203-3044 Email cj@interlog.com Christopher R. Jones, P.Eng. 14 Oneida Avenue Toronto, Ontario M5J 2E3 Tel. 416 203-7465 Fax. 416 203-3044 Email cj@interlog.com From gcc-return-9486-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 13:29:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4979 invoked by alias); 25 Aug 1999 13:29:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4957 invoked from network); 25 Aug 1999 13:29:25 -0000 Received: from smtp1.cern.ch (137.138.128.38) by egcs.cygnus.com with SMTP; 25 Aug 1999 13:29:25 -0000 Received: from pcep-jamie.cern.ch (pcep-jamie.cern.ch [137.138.38.126]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id PAA30439; Wed, 25 Aug 1999 15:29:20 +0200 (MET DST) Received: (from jamie@localhost) by pcep-jamie.cern.ch (8.9.3/8.9.3) id PAA07401; Wed, 25 Aug 1999 15:29:19 +0200 Date: Wed, 25 Aug 1999 15:29:19 +0200 From: Jamie Lokier To: Jason Merrill Cc: "George T. Talbot" , Ulrich Drepper , Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Message-ID: <19990825152919.A7384@pcep-jamie.cern.ch> References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> <37C31585.B71A8BA2@moberg.com> <19990825022834.B6865@pcep-jamie.cern.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from Jason Merrill on Tue, Aug 24, 1999 at 07:57:12PM -0700 Jason Merrill wrote: > .eh_frame has nothing to do with how many handlers a function has; it tells > the unwinder how to reload the registers saved in the function prologue so > that they have the right values when we get to a handler in the caller. Thanks, I'd completely missed that. > Another possiblity would be to declare that all registers are clobbered on > entry to an exception handler; then the default unwinder would only have to > worry about how to find the return address and saved stack pointer for a > frame, which is usually straightforward if you have a frame pointer to work > with. For functions without exception handlers (including all current C), that would reduce .eh_frame while leaving the code the same. For functions with exception handlers, it would mean slightly code in the non-exception case. Q: Do we prefer 1. smaller .eh_frame info and the same code as now 2. worse code in the non-exception path of code that has exception handlers? Bear in mind most C++ functions would be affected by 2. -- Jamie From gcc-return-9487-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 13:30:17 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5439 invoked by alias); 25 Aug 1999 13:30:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5299 invoked from network); 25 Aug 1999 13:30:00 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 25 Aug 1999 13:30:00 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id KAA19755; Wed, 25 Aug 1999 10:25:27 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id JAA05811; Wed, 25 Aug 1999 09:58:50 -0300 (EST) To: "Christopher R. Jones" , Fredrik =?iso-8859-1?q?=D6hrstr=F6m?= Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: Strange behaviour in C++... References: <3.0.32.19990825075547.009b3930@mail.interlog.com> From: Alexandre Oliva Date: 25 Aug 1999 10:02:45 -0300 In-Reply-To: "Christopher R. Jones"'s message of "Wed, 25 Aug 1999 07:55:48 -0400" Message-ID: Lines: 22 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit On Aug 25, 1999, "Christopher R. Jones" wrote: > I am puzzled at the lack of attention this thread has received. Maybe it's because it's a known bug, that has been pestering GNU/Linux forever, because of the choice to enable -fvtable-thunks by default quite a long time ago, for performance reasons, despite the bug? :-) In fact, I seem to recall there was an attempt to fix it for gcc 2.95 (was it Martin v. Löewis?), but, if it ever got in the CVS tree, it seems that it didn't work for this case :-( I'm installing the following testcase in the testsuite: --=-=-= Content-Type: text/x-c++ Content-Disposition: inline; filename=thunk1.C Content-Transfer-Encoding: quoted-printable // Copyright (C) 1999 Free Software Foundation // by Alexandre Oliva // based on bug report by Fredrik =D6hrstr=F6m // Special g++ Options: -fvtable-thunks // execution test - XFAIL *-*-* #include using namespace std; struct vbase { virtual int get_a() const =3D 0; }; struct base: virtual vbase { int a; base(int aa) : a(aa) {} int get_a() const { return a; } }; struct mid: base { mid(int bb) : base(bb) { // when mid is not in charge of vbase initialization, // a derived-aware vtable is needed for vbase if (((vbase*)this)->get_a() !=3D bb) abort(); } }; struct derived: virtual mid { derived(int cc) : mid(cc) {} }; int main () { derived(1); } --=-=-= -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them --=-=-=-- From gcc-return-9488-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 13:31:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6143 invoked by alias); 25 Aug 1999 13:31:38 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6101 invoked from network); 25 Aug 1999 13:31:35 -0000 Received: from timbuk-fddi.cray.com (HELO timbuk-e1.cray.com) (128.162.8.102) by egcs.cygnus.com with SMTP; 25 Aug 1999 13:31:35 -0000 Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by timbuk-e1.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id IAA05391 for ; Wed, 25 Aug 1999 08:31:32 -0500 (CDT) Received: from ironwood-e185.cray.com (root@ironwood-e185.cray.com [128.162.185.212]) by ledzep.cray.com (8.9.3/craymail-smart) with ESMTP id IAA8173892 for ; Wed, 25 Aug 1999 08:31:31 -0500 (CDT) Received: from sgi044.cray.com (sgi044 [128.162.195.55]) by ironwood-e185.cray.com (8.8.4/ASC-news-e1.0) with ESMTP id IAA13221 for ; Wed, 25 Aug 1999 08:31:30 -0500 (CDT) Received: from localhost by sgi044.cray.com (8.8.8/SGI-client.1.6) via ESMTP id IAA06792; Wed, 25 Aug 1999 08:31:29 -0500 (CDT) Date: Wed, 25 Aug 1999 08:31:28 -0500 From: James Beyer X-Sender: beyerj@sgi044.cray.com To: gcc@gcc.gnu.org Subject: printf format string Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII What is the expected output if an argument does not have the appropriate types for the string format specified? Is the argument just cast into the correct format, with casting rules applied? Or is the output undefined in some cases? This seems like it may be implementation dependent. james From gcc-return-9489-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 13:36:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8130 invoked by alias); 25 Aug 1999 13:36:54 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8106 invoked from network); 25 Aug 1999 13:36:52 -0000 Received: from smtp1.cern.ch (137.138.128.38) by egcs.cygnus.com with SMTP; 25 Aug 1999 13:36:52 -0000 Received: from pcep-jamie.cern.ch (pcep-jamie.cern.ch [137.138.38.126]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id PAA00903; Wed, 25 Aug 1999 15:36:48 +0200 (MET DST) Received: (from jamie@localhost) by pcep-jamie.cern.ch (8.9.3/8.9.3) id PAA07411; Wed, 25 Aug 1999 15:36:47 +0200 Date: Wed, 25 Aug 1999 15:36:47 +0200 From: Jamie Lokier To: Jason Merrill Cc: "George T. Talbot" , Ulrich Drepper , Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Message-ID: <19990825153647.B7384@pcep-jamie.cern.ch> References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> <37C31585.B71A8BA2@moberg.com> <19990825022834.B6865@pcep-jamie.cern.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from Jason Merrill on Tue, Aug 24, 1999 at 07:57:12PM -0700 Jason Merrill wrote: > >>>>> Jamie Lokier writes: > > > I would think improving the .eh_frame info so that functions without > > unwind handlers don't take any space in .eh_frame. I.e., some mechanism > > for "default unwinding" using the frame pointer. > > .eh_frame has nothing to do with how many handlers a function has; it tells > the unwinder how to reload the registers saved in the function prologue so > that they have the right values when we get to a handler in the caller. > > It is possible to do unwinding without .eh_frame; gdb does it by > disassembling the prologue, but this doesn't always work. > > Another possiblity would be to declare that all registers are clobbered on > entry to an exception handler; then the default unwinder would only have to > worry about how to find the return address and saved stack pointer for a > frame, which is usually straightforward if you have a frame pointer to work > with. Possibility #2: do the disassembly thing as GDB does, but emit .eh_frame info and unwinding code for functions where that would not work. Complicated to implement. Possibility #3: store a compact, special entry in .eh_frame per function that means "unwind using frame pointer, and restore regs from base of stack where REGMASK has bits set for regs to restore". As usual, normal .eh_frame+unwinder for cases where this fails, if any. Possibility #4: the epilogue for a function normally balances the prologue. A 12 byte entry in .eh_frame (or smaller if compressed) that contains the start address of the function, the address of the epilogue, and the stack offset relative to the frame pointer, should work in most cases. 12 bytes in .eh_frame for each function that clobbers any callee-saved registers is not much overall. -- Jamie From gcc-return-9490-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 14:19:17 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18767 invoked by alias); 25 Aug 1999 14:19:02 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18724 invoked from network); 25 Aug 1999 14:18:52 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 25 Aug 1999 14:18:52 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id 6E39632D10; Wed, 25 Aug 1999 16:18:12 +0200 (MEST) Received: from Wotan.suse.de (Wotan.suse.de [10.10.0.1]) by Galois.suse.de (Postfix) with ESMTP id 7B53C67A8; Wed, 25 Aug 1999 16:18:11 +0200 (MEST) Received: from hawking.suse.de (Hawking.suse.de [10.10.0.89]) by Wotan.suse.de (Postfix) with ESMTP id 3D4B97F8B; Wed, 25 Aug 1999 16:18:23 +0200 (MEST) Received: (from schwab@localhost) by hawking.suse.de (8.9.3/8.9.3) id QAA20166; Wed, 25 Aug 1999 16:18:23 +0200 To: James Beyer Cc: gcc@gcc.gnu.org Subject: Re: printf format string References: X-Yow: Not enough people play SKEE-BALL.. They're always thinking about COCAINE or and ALIEN BEINGS!! From: Andreas Schwab Date: 25 Aug 1999 16:18:23 +0200 In-Reply-To: James Beyer's message of "Wed, 25 Aug 1999 08:31:28 -0500" Message-ID: Lines: 11 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit James Beyer writes: |> What is the expected output if an argument does not have the appropriate |> types for the string format specified? Undefined behaviour will occur, anything can happen. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg From gcc-return-9491-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 14:33:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20554 invoked by alias); 25 Aug 1999 14:33:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20537 invoked from network); 25 Aug 1999 14:33:20 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 25 Aug 1999 14:33:20 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id KAA04073 for ; Wed, 25 Aug 1999 10:33:18 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (root@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id KAA25484 for ; Wed, 25 Aug 1999 10:31:02 -0400 (EDT) Received: (qmail 27495 invoked by uid 500); 25 Aug 1999 14:29:42 -0000 Date: 25 Aug 1999 14:29:42 -0000 Message-ID: <19990825142942.27494.qmail@deer> To: gvwilson@interlog.com CC: gcc@gcc.gnu.org cc: craig@jcb-sc.com In-reply-to: <3.0.6.32.19990824224955.007cb170@mail.interlog.com> (message from Greg Wilson on Tue, 24 Aug 1999 22:49:55 -0400) Subject: Re: case of G77 symbol tables References: <3.0.6.32.19990824224955.007cb170@mail.interlog.com> >Hi. I'm trying to call Fortran compiled with g77 from C >on Windows NT. When I run 'nm' on the '.obj' produced by >g77, it tells me that my function names have all been turned >into lower case, i.e. 'setLowThresh' has become 'setlowthresh'. >This is causing some of my other tools trouble. Is this case >change deliberate? Can it be controlled by a command-line >switch? (I couldn't find one in the docs.) See -fsource-case-preserve and similar options. Though solving that might be only the beginning when it comes to getting such things working...the comp.lang.fortran FAQ might be, or point to, a useful resource for further info on language mixing. tq vm, (burley) From gcc-return-9492-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 14:33:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20732 invoked by alias); 25 Aug 1999 14:33:35 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20710 invoked from network); 25 Aug 1999 14:33:34 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 25 Aug 1999 14:33:34 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id KAA04102 for ; Wed, 25 Aug 1999 10:33:32 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (root@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id KAA25675 for ; Wed, 25 Aug 1999 10:31:22 -0400 (EDT) Received: (qmail 27475 invoked by uid 500); 25 Aug 1999 14:28:19 -0000 Date: 25 Aug 1999 14:28:19 -0000 Message-ID: <19990825142819.27474.qmail@deer> To: jstern@citilink.com CC: jbuck@synopsys.com, jstern@citilink.com, gcc@gcc.gnu.org, george@moberg.com cc: craig@jcb-sc.com In-reply-to: <199908250052.TAA13322@foshay.citilink.com> (message from Josh Stern on Tue, 24 Aug 1999 19:52:19 -0500 (CDT)) Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <199908250052.TAA13322@foshay.citilink.com> >Of course the chance of getting a signal that you want to throw on >just as malloc() returns, combined with the situation where you >actually care about the memory leak at this juncture, combined >with the situation where the last catch that is released isn't >going to just free a whole epoch of allocations, is an >extremely low probability circumstance. I understood the >example but thought of this case as being lost in the 'noise'. Not that I've been paying close attention to this thread or anything, but if you're talking about how a *system* should be designed, rather than how a specific *application* (say, a game or a kiosk display or the guidance system for a nuclear missile), there's no such thing as a window like this being lost in the "noise". In short, when designing a system like a general-purpose compiler, operating system, and so on, assume every window of opportunity for lossage approaches being infinitely wide. If lossage is still acceptable, then fine, else the mere opportunity is unacceptable. (Whereas, for an application, you can refine your analysis to take into account the risks if the window is hit. If the game simply crashes and that's okay, or if the kiosk system can simply and quickly reboot without losing any important data, fine. The missile is, of course, a whole 'nother story.) For example, the probability of an async exception taking effect between the end of a critical (protected) region within the malloc() code and the storing of the pointer into the variable is at least two orders of magnitude *higher* than most programmers would reckon based on their simplistic analysis of the instruction stream executed. (This is due to higher likelihoods of cache, TLB, and resident-page misses upon returning from a procedure than while executing typical straightline code. Add to that whatever code gets executed to exit the critical region....) Further, while the *overall* likelihood of a window like this being hit might be statistically small, in a *given* application that happens to have an exposure to ill effects from it, especially in a given *deployment* of that application, the likelihood might near 100% within a reasonably small timeframe. (It would not be too strange, to me, to hear that an application built on a system with bugs like this failed *only* on one out of thousands of machines on which it's deployed, the only difference being that that one machine is a 400MHz Pentium III while all the others are 433MHz, for example.) I've seen too many projects and products take *huge* hits in perceived robustness, utility, and wasted developer/debugging time due to supposedly "vanishingly small" windows like this being pried open, by various combinations of circumstances, to the point of repeated failure, to ever again accept "lost in the noise" as an excuse for designing in such windows. Further, few people who say things like "lost in the noise" understand the fine distinctions between *types* of noise. In this case, I hope you don't consider synchronous bugs (bugs triggered by normal, straightline code) as in any way similar to asynchronous bugs. Excellent programmers can do a great job squashing the former kind -- very few understand how to even begin setting up a test bed that finds the latter (I could only *begin* to guess at that, myself, offhand). My impression is that at least some people in this discussion already understand these issues, perhaps all of them. My guess is that if, indeed, the problem mentioned is "lost in the noise", then the overall mechanism must be thoroughly explained as not able to cope with those sorts of coding constructs (to wit, pretty much any means a programmer might typically use to test how far some chunk of imperative code progressed before hitting a signal). That shouldn't be surprising or worrisome, given that C, C++, Fortran, etc. were not designed from the ground up as "transaction-based" languages...but I think too many programmers are under the impression they work that way by magic. The transition the vast majority of today's programmers have gone through, of single-user/single-task PC over to multi-user/multi-task/multi-node/dynamically-partitioning Internet (e.g. client/server programming), seems to have left a lot of them doing the latter sort of programming without even realizing they don't know how. (In that sense, I was "lucky", having cut my teeth on timesharing systems before there were PC's, and having come so "late to the [PC] game" that they were already beginning to discover multi-tasking, so I had little opportunity to gain ground by "forgetting" all the OS-design worries I'd picked up over the years.) That being said, my experience *before* the PC industry suggested that most programmers (even *good* ones) didn't know how to architect, design, or implement robust systems involving inherently asynchronous activities, and yet were unaware of the issues and therefore thought they could. It's painful work getting this stuff right -- I remember spending *hours* just verifying that a particular shared-resource management scheme, implementing very simple primitives, was bullet-proof. Not fun, but necessary, especially since I didn't want to have to debug the async aspects of the code I was writing. In that case, I'd already had to completely overhaul the *architecture* and *design* of the system, after more experienced programmers hadn't even thought about what it would take to make it bullet-proof at those levels. tq vm, (burley) P.S. In case anyone's thinking "gee, Craig, if you think about it, you're essentially saying most programmers, and therefore most programs, don't really work in the presence of exceptions, especially asynchronous ones", all I can say is, yes, I've already thought about that, and, indeed, tentatively come to that conclusion. But I've done very little reading up on today's concepts of exceptions, asynchronous or otherwise -- last I really paid attention to these issues, I was reasonably solid on the relevant Multics-like concepts. Perhaps today's designers have worked out the kinks, but my general impression is that the architects of Multics took things much more seriously than do today's (for both good and ill). And the programmers who tried to properly use the underlying, *robust* technologies like signals often failed, despite there being very few of them, and despite their being permitted to do such programming only after having spent a few years in a cave with a guru, so I alternate between hoping today's whiz-kid programmers "just get" this stuff and fearing they're basically completely clueless about it, as they design and build the Global Infrastructure Of The New Millenium. ;-) From gcc-return-9493-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 14:55:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26963 invoked by alias); 25 Aug 1999 14:55:40 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26937 invoked from network); 25 Aug 1999 14:55:37 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 25 Aug 1999 14:55:37 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id KAA04763; Wed, 25 Aug 1999 10:53:54 -0400 Message-ID: <37C4051A.AB83FBA6@moberg.com> Date: Wed, 25 Aug 1999 15:00:42 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ulrich Drepper CC: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> <37C31A14.6817336D@moberg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ulrich Drepper wrote: > > "George T. Talbot" writes: > > > What would be an acceptable size increase? Did the people who > > complained say what would be acceptable or did they just complain? > > ;^) > > The latter, of course. ;^) > > What methods do you guys use now to determine what is and what isn't > > an acceptable performance hit when, say, you're experimenting with > > different compiler optimization flags? > > I don't have to run performance data. If a feature effects everybody > and is hardly used by anybody it's not worth it. If the effect is > minimal (i.e., a handful of additional assembler instruction or a few > bytes of data where needed) this is ok. But simply enabling > fexceptions is not. OK. I understand. > > I'm trying to get an idea of what is and what isn't acceptable. I > > have no problem doing the hard work of implementing a fix to > > pthread_cancel() under Linux, and I have no problem doing the hard > > work of measurement, but I need some objective criteria for doing > > the measurement so I don't walk down a dead-end path. > > I like the idea of using the exception mechanism to handle cancelation > even in C. So what has to be done is: > > - implement a usable interface to the exception handling in gcc (not g++). > It must be possible to define macros named pthread_cleanup_push() and > pthread_cleanup_pop() and use them like this: > > pthread_cleanup_push (func, arg); > > ... do lots of work ... > > if (some condition) > { > ... do what is necessary to leave the frame ... > return; > } > > ... more work ... > > pthread_cleanup_pop (doit); > > This roughly has to be converted to something like: > > try > { > ... do lots of work ... > > if (some condition) > return; > > ... more work ... > > if (doit) > throw (_posix_cancelation_exception_object); > // Alternatively do the call directly: > // func (arg); > }; > catch (_POSIX_CANCELATION_EXCEPTION &exc) > { > func (arg); > }; Yup. This is exactly what I was thinking. > I.e.: > > + leaving the frame must somehow be handled I asked the author of Programming POSIX Threads (David Butenhof) who said that the standard doesn't really define that case, but that programs which use return to avoid pthread_cleanup_pop() aren't portable. He said that it was acceptable for an implementation to do an implicit pthread_cleanup_pop(0), which is what your example would do. So, in other words, no problem. ;^) By the way, won't the current implementation have a problem with this case? > + the function to be called (and it's always only one function) is > named in the push call at the beginning (contrary to the C++ > syntax) I think what ends up happening is something like this: pthread_cleanup_push(blah, arg); ... do_work(); ... pthread_cleanup_pop(execute); is transformed via macro expansion to: { \ void (*__function) (void *) = blah; | void *__arg = arg; | pthread_cleanup_push() | __try | { / ... do_work(); ... } \ __catch (...) | { | pthread_cleanup_pop() __function(arg); | __throw; | } | if (execute) __function(arg); | } / (I'm not sure whether the above should be __catch(...) or __catch(POSIX_cancel c). I could argue for either one.) > + one must be able to throw an exception (in the example above as > well as in the cancelation call of the library) Yup. I'd need to be able to throw an exception so that I could do the re-throw above. I'm not sure whether the above should be __catch(...) or __catch(POSIX_cancel c). > - functions which must be compiled with exception handling enabled must > be identified. These include: > > + functions which are cancelation points: > > + functions which use callbacks and those directly or indirectly using > functions which use callbacks Personally, the above __try...__catch stuff, the patch to pthread_exit() to perform a __throw at the right time, and possibly the patch to the compiler to add exception support to C I can do. Identifying the functions which need -fexceptions starts to get me in water over my head, as I don't know the C library that well. I agree that this needs to be done. I'm just saying that it's a problem that I don't know that I could get right, as I don't have enough experience and familiarity with the C library. Is there an automated way of doing this? I also get the feeling from other posts by the compiler guys on this topic is that this issue has made them think about optimizing the unwinding information to take up less space. It sure would be nice to avoid the issue entirely. ;^) > If things are implemented this way I could argue that the new scheme > should be used since it is probably faster than the current implementation. I hadn't thought of that. > If you can come up with a scheme which works for the case above (I > hope I covered all cases) I'd like to learn about it. If I (or someone else, but I get the feeling that I'm volunteering ;^) can come up with a good patch for GCC to add exception support to C, which seems to be something that the people on the compiler list like, then I've got no problem with the scheme above. -- George T. Talbot From gcc-return-9494-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 15:38:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5736 invoked by alias); 25 Aug 1999 15:37:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5699 invoked from network); 25 Aug 1999 15:37:51 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 25 Aug 1999 15:37:51 -0000 Received: from otr.mynet (dialin-sv-02.cygnus.com [205.180.231.52]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA28986; Wed, 25 Aug 1999 08:37:42 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.9.3/8.9.3/ud-990718) id IAA07441; Wed, 25 Aug 1999 08:35:13 -0700 To: "George T. Talbot" Cc: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> <37C31A14.6817336D@moberg.com> <37C4051A.AB83FBA6@moberg.com> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Ulrich Drepper Date: 25 Aug 1999 08:35:12 -0700 In-Reply-To: "George T. Talbot"'s message of "Wed, 25 Aug 1999 15:00:42 +0000" Message-ID: Lines: 55 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Big Bend" "George T. Talbot" writes: > I asked the author of Programming POSIX Threads (David Butenhof) who > said that the standard doesn't really define that case, but that > programs which use return to avoid pthread_cleanup_pop() aren't > portable. I don't care whether it's unportable, I need this for the implementation. > By the way, won't the current implementation have a problem with this > case? No, since I call the underlying function. > { \ > void (*__function) (void *) = blah; | > void *__arg = arg; | pthread_cleanup_push() > | > __try | > { / > ... > do_work(); > ... > } \ > __catch (...) | > { | pthread_cleanup_pop() > __function(arg); | > __throw; | > } | > if (execute) __function(arg); | > } / What I hope to get are optimizations. E.g., the function is constant. Therefore the compiler should put a function pointer in an appropriate place where it does not have to be loaded each time. Since the access in the __catch part is generated by the compiler as well it can know where to get the value from. > (I'm not sure whether the above should be __catch(...) or > __catch(POSIX_cancel c). I could argue for either one.) The latter. > I agree that this needs to be done. I'm just saying that it's a problem > that I don't know that I could get right, as I don't have enough > experience and familiarity with the C library. Is there an automated > way of doing this? One could find this out partially using some scripts but they need in some cases help from people and also have to rerun after every change. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gcc-return-9495-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 15:43:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7392 invoked by alias); 25 Aug 1999 15:43:23 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7351 invoked from network); 25 Aug 1999 15:43:19 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 25 Aug 1999 15:43:19 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id IAA27588; Wed, 25 Aug 1999 08:41:36 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id IAA16903; Wed, 25 Aug 1999 08:41:35 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id IAA18967; Wed, 25 Aug 1999 08:41:35 -0700 Message-Id: <199908251541.IAA18967@atrus.synopsys.com> Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads To: craig@jcb-sc.com Date: Wed, 25 Aug 99 8:41:34 PDT Cc: jstern@citilink.com, jbuck@synopsys.com, gcc@gcc.gnu.org, george@moberg.com In-Reply-To: <19990825142819.27474.qmail@deer>; from "craig@jcb-sc.com" at Aug 25, 99 2:28 pm X-Mailer: ELM [version 2.3 PL11] Craig Burley, writing in the async interrupts debate. > Further, few people who say things like "lost in the noise" understand > the fine distinctions between *types* of noise. In this case, I hope > you don't consider synchronous bugs (bugs triggered by normal, > straightline code) as in any way similar to asynchronous bugs. > Excellent programmers can do a great job squashing the former > kind -- very few understand how to even begin setting up a test > bed that finds the latter (I could only *begin* to guess at that, > myself, offhand). You use the techniques hardware engineers do. Digital oscilloscopes to capture bus transactions; traces to capture every instruction executed, stuff like that. I've been there. > That being said, my experience *before* the PC industry suggested that > most programmers (even *good* ones) didn't know how to architect, design, > or implement robust systems involving inherently asynchronous activities, Even hardware engineers have problems with asynchronous designs, which is why almost all circuit design is synchronous (using a clock), even though in theory asynchronous circuits can be cheaper, more efficient, and consume much lower power (CMOS logic consumes almost no power except when signals switch, and with async we never change the value of a signal unless there is real meaning to communicate, since there is no clock). The problem is that except for tiny circuits, it's exceedingly difficult to get them right, and there's always a non-zero probability of failure (though this probability can be made arbitrarily small, e.g. one failure per century or the like). So in practice small bits of async logic are used to communicate between and synchronize with large regions of synchronous logic. > and yet were unaware of the issues and therefore thought they could. > It's painful work getting this stuff right -- I remember spending *hours* > just verifying that a particular shared-resource management scheme, > implementing very simple primitives, was bullet-proof. Formal verification techniques have been used successfully here; for instance, pretty much everyone doing multiprocessor hardware now does formal verification for their cache coherency protocol. But these techniques need some skill to use. > P.S. In case anyone's thinking "gee, Craig, if you think about it, > you're essentially saying most programmers, and therefore most programs, > don't really work in the presence of exceptions, especially asynchronous > ones", all I can say is, yes, I've already thought about that, and, > indeed, tentatively come to that conclusion. I think that you're lumping two things together here: synchronous exceptions are just branches, with a limited number of sources and destinations. It's async exceptions that make life horrific. From gcc-return-9496-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 15:57:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9730 invoked by alias); 25 Aug 1999 15:57:16 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9713 invoked from network); 25 Aug 1999 15:57:11 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 25 Aug 1999 15:57:11 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id IAA28558; Wed, 25 Aug 1999 08:56:43 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id IAA20392; Wed, 25 Aug 1999 08:56:43 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id IAA19192; Wed, 25 Aug 1999 08:56:43 -0700 Message-Id: <199908251556.IAA19192@atrus.synopsys.com> Subject: Re: printf format string To: beyerj@sgi.com (James Beyer) Date: Wed, 25 Aug 99 8:56:42 PDT Cc: gcc@gcc.gnu.org In-Reply-To: ; from "James Beyer" at Aug 25, 99 8:31 am X-Mailer: ELM [version 2.3 PL11] > What is the expected output if an argument does not have the appropriate > types for the string format specified? A program crash may occur in many cases; in other cases garbage is printed. > Is the argument just cast into the correct format, with casting rules > applied? Or is the output undefined in some cases? No, no casts occur, because the compiler does not attempt to read and interpret the format string. From gcc-return-9497-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 16:09:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13152 invoked by alias); 25 Aug 1999 16:09:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13010 invoked from network); 25 Aug 1999 16:08:38 -0000 Received: from brain.moberg.com (207.8.227.1) by egcs.cygnus.com with SMTP; 25 Aug 1999 16:08:38 -0000 Received: from moberg.com (dhcp41.moberg.com [207.8.227.41]) by brain.moberg.com (8.8.7/8.8.7) with ESMTP id MAA05471; Wed, 25 Aug 1999 12:06:44 -0400 Message-ID: <37C4162E.87F482A@moberg.com> Date: Wed, 25 Aug 1999 16:13:34 +0000 From: "George T. Talbot" Organization: Moberg Research, Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.11 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ulrich Drepper CC: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> <37C31A14.6817336D@moberg.com> <37C4051A.AB83FBA6@moberg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ulrich Drepper wrote: > > "George T. Talbot" writes: > > > I asked the author of Programming POSIX Threads (David Butenhof) who > > said that the standard doesn't really define that case, but that > > programs which use return to avoid pthread_cleanup_pop() aren't > > portable. > > I don't care whether it's unportable, I need this for the implementation. I don't understand what you need. Do you need the return to actually call some function like _pthread_cleanup_pop()? > > By the way, won't the current implementation have a problem with this > > case? > > No, since I call the underlying function. I'm not sure exactly what you're saying. glibc 2.1.1 has the following in : #define pthread_cleanup_push(routine,arg) \ { struct _pthread_cleanup_buffer _buffer; \ _pthread_cleanup_push (&_buffer, (routine), (arg)); extern void _pthread_cleanup_push __P ((struct _pthread_cleanup_buffer *__buffer, void (*__routine) (void *), void *__arg)); /* Remove a cleanup handler installed by the matching pthread_cleanup_push. If EXECUTE is non-zero, the handler function is called. */ #define pthread_cleanup_pop(execute) \ _pthread_cleanup_pop (&_buffer, (execute)); } So, the expansion in the user code looks like this: pthread_cleanup_push(blah, arg); ... do_work(); ... if (something) return; ... pthread_cleanup_pop(execute); expands to { struct _pthread_cleanup_buffer _buffer; _pthread_cleanup_push(&_buffer, (blah), (arg)); ... do_work(); ... if (something) return; ... _pthread_cleanup_pop(&_buffer, (execute)); } If something is TRUE, and the function returns at the return statement, then _pthread_cleanup_pop(&_buffer, (execute)) will not get called, and the library will leave the cleanup handler registered when the scope is exited. That doesn't seem right. Here's a test program. #include #include void cleanup(void *arg) { printf("cleanup runs.\n"); fflush(stdout); } void test(int something, int execute) { printf("\n\nsomething=%d, execute=%d: ", something, execute); fflush(stdout); pthread_cleanup_push(cleanup, 0); if (something) return; pthread_cleanup_pop(execute); } int main(int argc, char *argv[]) { test(0, 0); test(0, 1); test(1, 0); test(1, 1); } Here's the output: $ ./a.out something=0, execute=0: something=0, execute=1: cleanup runs. something=1, execute=0: something=1, execute=1: In the fourth case, the cleanup has not run. This is glibc 2.1.1. I suspect, also, that when something is TRUE, that the cleanup handler is still registered with the C library so that if the thread is cancelled, the cleanup will run even though the scope is exited. In other words, if the thread is cancelled after the fourth call to test(1,1), then the cleanup would run. Is that correct behavior? I would think that the cleanup should only run if the thread is cancelled when the cleanup scope is still active. Using exceptions works the same, except that there is no problem with cleanup handlers remaining registered, as the library would no longer keep track of cleanup handlers, and the normal stack unwind would take care of cases like the one above. > > { \ > > void (*__function) (void *) = blah; | > > void *__arg = arg; | pthread_cleanup_push() > > | > > __try | > > { / > > ... > > do_work(); > > ... > > } \ > > __catch (...) | > > { | pthread_cleanup_pop() > > __function(arg); | > > __throw; | > > } | > > if (execute) __function(arg); | > > } / > > What I hope to get are optimizations. E.g., the function is constant. > Therefore the compiler should put a function pointer in an appropriate > place where it does not have to be loaded each time. Since the access > in the __catch part is generated by the compiler as well it can know > where to get the value from. I think that you are correct, and the compiler would in fact recognize that __function and __arg are constant. > > (I'm not sure whether the above should be __catch(...) or > > __catch(POSIX_cancel c). I could argue for either one.) > > The latter. OK. > > I agree that this needs to be done. I'm just saying that it's a problem > > that I don't know that I could get right, as I don't have enough > > experience and familiarity with the C library. Is there an automated > > way of doing this? > > One could find this out partially using some scripts but they need in > some cases help from people and also have to rerun after every change. Since a compiler patch is required to add exceptions to C anyway, maybe we could talk the GCC folks into optimizing their exception information so that the space problem would just go away. ;^) -- George T. Talbot From gcc-return-9498-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 16:14:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15693 invoked by alias); 25 Aug 1999 16:14:31 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15660 invoked from network); 25 Aug 1999 16:14:30 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 25 Aug 1999 16:14:30 -0000 Received: from otr.mynet (dialin-sv-02.cygnus.com [205.180.231.52]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA02201; Wed, 25 Aug 1999 09:14:24 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.9.3/8.9.3/ud-990718) id JAA07530; Wed, 25 Aug 1999 09:11:55 -0700 To: "George T. Talbot" Cc: Oleg Krivosheev , gcc@gcc.gnu.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <37BC20BA.E8C4E7F2@moberg.com> <37C3084C.BC7CBE89@moberg.com> <37C31A14.6817336D@moberg.com> <37C4051A.AB83FBA6@moberg.com> <37C4162E.87F482A@moberg.com> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Ulrich Drepper Date: 25 Aug 1999 09:11:55 -0700 In-Reply-To: "George T. Talbot"'s message of "Wed, 25 Aug 1999 16:13:34 +0000" Message-ID: Lines: 19 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Big Bend" "George T. Talbot" writes: > I don't understand what you need. Do you need the return to actually > call some function like _pthread_cleanup_pop()? Yes. > If something is TRUE, and the function returns at the return statement, > then _pthread_cleanup_pop(&_buffer, (execute)) will not get called, and > the library will leave the cleanup handler registered when the scope is > exited. That doesn't seem right. I'm calling n some situations _pthread_cleanup_pop directly. I can do this since the thread library is also part of glibc. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gcc-return-9499-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 16:43:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30813 invoked by alias); 25 Aug 1999 16:43:02 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30720 invoked from network); 25 Aug 1999 16:42:56 -0000 Received: from waldo.fnal.gov (root@131.225.18.213) by egcs.cygnus.com with SMTP; 25 Aug 1999 16:42:56 -0000 Received: from wally.fnal.gov (wally [131.225.18.158]) by waldo.fnal.gov (8.9.1b+Sun/8.9.1) with ESMTP id LAA09699; Wed, 25 Aug 1999 11:42:46 -0500 (CDT) Received: from localhost (kriol@localhost) by wally.fnal.gov (8.9.1b+Sun/8.9.1) with ESMTP id LAA15761; Wed, 25 Aug 1999 11:42:44 -0500 (CDT) X-Authentication-Warning: wally.fnal.gov: kriol owned process doing -bs Date: Wed, 25 Aug 1999 11:42:40 -0500 (CDT) From: Oleg Krivosheev X-Sender: kriol@wally.fnal.gov To: "George T. Talbot" cc: Ulrich Drepper , Oleg Krivosheev , gcc@gcc.GNU.org, libc-alpha@sourceware.CYGNUS.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads In-Reply-To: <37C31A14.6817336D@moberg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, On Tue, 24 Aug 1999, George T. Talbot wrote: > Ulrich Drepper wrote: > > > > "George T. Talbot" writes: > > > > > The size went from 1.2MB to 1.4MB. Is that an acceptable size > > > increase? > > > > Certainly not. This increase is completely unused in most cases. > > What would be an acceptable size increase? Did the people who > complained > say what would be acceptable or did they just complain? ;^) i thought all (well, 99%) addition went to rodata or equivalent section, so if it is not used, is is not paged in. Could you please run size -A on old and new library and tell where the difference went? > > > > As to performance, do you have a standard method of measuring overall > > > performance? > > > > No. > > What methods do you guys use now to determine what is and what isn't an > acceptable performance hit when, say, you're experimenting with > different > compiler optimization flags? > > I'm trying to get an idea of what is and what isn't acceptable. I have > no problem doing the hard work of implementing a fix to pthread_cancel() > under Linux, and I have no problem doing the hard work of measurement, > but > I need some objective criteria for doing the measurement so I don't walk > down a dead-end path. umm... cam run some computational tests for you but not sure it will stress the difference... OK From gcc-return-9500-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 17:11:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19556 invoked by alias); 25 Aug 1999 17:11:07 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19445 invoked from network); 25 Aug 1999 17:11:04 -0000 Received: from citycenter.citilink.com (root@209.98.8.5) by egcs.cygnus.com with SMTP; 25 Aug 1999 17:11:04 -0000 Received: from foshay.citilink.com (jstern@foshay.citilink.com [209.98.8.9]) by citycenter.citilink.com (8.8.8/8.7.5) with ESMTP id MAA00540 for ; Wed, 25 Aug 1999 12:09:05 -0500 (CDT) Received: (from jstern@localhost) by foshay.citilink.com (8.8.8/8.7.5) id MAA29103 for gcc@gcc.gnu.org; Wed, 25 Aug 1999 12:10:54 -0500 (CDT) Date: Wed, 25 Aug 1999 12:10:54 -0500 (CDT) From: Josh Stern Posted-Date: Wed, 25 Aug 1999 12:10:54 -0500 (CDT) Message-Id: <199908251710.MAA29103@foshay.citilink.com> To: gcc@gcc.gnu.org Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Craig wrote: >Josh wrote: >>Of course the chance of getting a signal that you want to throw on >>just as malloc() returns, combined with the situation where you >>actually care about the memory leak at this juncture, combined >>with the situation where the last catch that is released isn't >>going to just free a whole epoch of allocations, is an >>extremely low probability circumstance. I understood the >>example but thought of this case as being lost in the 'noise'. >Not that I've been paying close attention to this thread or anything, >but if you're talking about how a *system* should be designed, >rather than how a specific *application* (say, a game or a kiosk >display or the guidance system for a nuclear missile), there's no >such thing as a window like this being lost in the "noise". Thanks Craig, for a long and thoughtful essay. A couple of points of response. First off, some attention to the rest of the thread would be required to understand the context of the text quoted above. Part of that context was contained in the rest of the excerpted post, which went on to describe a scheme for solving the problem that I understood to be proposed by Joe: a) preserving the legacy malloc() interface and b) avoiding even the possibility of a memory leak in the presence of asynchronous exceptions. A couple of people, including you, have jumped on the word choice "lost in the noise", but nobody seemed to object to the argument that one could, after all, design a malloc that didn't have the possibility of leaking in the presence of asynchronous exceptions. At least the fact that I included the discussion should have been a good clue that I didn't mean to suggest that "lost in the noise" referred to every need and situation. Also, your response doesn't really address even all of what is quoted above. Clearly, I am not saying that the time window is lost in the noise, but rather that the *combination* of the time window for a signal at just that juncture, with a signal that is a case to throw(), with a one-time memory leak (of small size - otherwise make use of the other interface), with an architecture that isn't reclaiming the memory through other means after such a throw - all of this combined is less likely to cause a visible performance problem in practice than say, a bug due to a compiler error. Perhaps you disagree with that, but at least please disagree with my actual opinion. >I've seen too many projects and products take *huge* hits in perceived >robustness, utility, and wasted developer/debugging time due to supposedly >"vanishingly small" windows like this being pried open, by various >combinations of circumstances, to the point of repeated failure, to >ever again accept "lost in the noise" as an excuse for designing in such >windows. See above. "Lost in the noise", while perhaps an unfortunate choice of words, was not meant to refer to the time window itself. >Further, few people who say things like "lost in the noise" understand >the fine distinctions between *types* of noise. In this case, I hope >you don't consider synchronous bugs (bugs triggered by normal, >straightline code) as in any way similar to asynchronous bugs. No, I don't. However, I think that I can effectively make a list of a relatively small number of circumstances where it would be conceivably appropriate to create an asynchronous exception by throwing from a signal handler, and that i.designing code that is as least as robust, if not more so, in the presence of this list of possibilities than it would have been if exceptions could not be thrown from signal handlers is easier than ii. designing exception-safe classes and procedures that will be robust in the face of synchronous throws from any functions they might call - so long as the definition of when to throw a synchronous exception is left in terms of statements like "the function cannot fulfill its contract given its arguments". >Excellent programmers can do a great job squashing the former >kind You've really raised the stakes in your commentary - talking about missile systems and the like. Here is my skeptical line in the sand: I don't believe, relative to this level of stakes, that even excellent programmers are fully dealing with the consequences of ii. Even if they could do it, they are not doing it in practice (I don't have occasion to look at any missile control code, but the code I do see isn't robust to every circumstance that could trigger a synchronous throw. What is minimally required to deal with even ii. is that a program be designed to move between states that have the kind of atomicity of a reliable database, so that exceptions cause a rollback of all variables and resources to a previous safe state. But, of course it is much worse than this because many applications deal with changing environments, so the previous "safe" state may no longer be safe - e.g. the missile has moved. The idea that designing exception safe classes makes their use safe in the presence of exceptions, independently of a context, is, I think, an illusion. >My guess is that if, indeed, the problem mentioned is "lost in the noise", >then the overall mechanism must be thoroughly explained as not able to >cope with those sorts of coding constructs (to wit, pretty much any >means a programmer might typically use to test how far some chunk of >imperative code progressed before hitting a signal). Just because the possibility of throwing from a signal handler is introduced, that doesn't mean that every signal will result in a throw, any more than the possibility that any random function could call _exit() needs to be protected for. >P.S. In case anyone's thinking "gee, Craig, if you think about it, >you're essentially saying most programmers, and therefore most programs, >don't really work in the presence of exceptions, especially asynchronous >ones", all I can say is, yes, I've already thought about that, and, >indeed, tentatively come to that conclusion. Well I agree with you - at the level of stakes you are talking about, most programs and programmers are broken. However, I may have some differences regarding assessment of where the greatest risks originate. - Josh From gcc-return-9501-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 17:33:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26595 invoked by alias); 25 Aug 1999 17:33:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26486 invoked from network); 25 Aug 1999 17:33:03 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 25 Aug 1999 17:33:03 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id LAA05666; Wed, 25 Aug 1999 11:30:10 -0600 X-Mailer: exmh version 2.0.2 To: Alexandre Oliva cc: "Christopher R. Jones" , gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: Strange behaviour in C++... Reply-To: law@cygnus.com In-reply-to: Your message of 25 Aug 1999 10:02:45 -0300. Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Aug 1999 11:30:09 -0600 Message-ID: <5663.935602209@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > In fact, I seem to recall there was an attempt to fix it for gcc 2.95= > (was it Martin v. L=F6ewis?), but, if it ever got in the CVS tree, it= > seems that it didn't work for this case :-( Just a note, thunks may be on their way out. I'm hearing more and more p= eople talk about the evils of thunks, particularly for high end processors. Depending on the changing winds, it may or may not be worth the time/effo= rt to fix the dynamic thunk problem. jeffv From gcc-return-9502-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 17:41:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29943 invoked by alias); 25 Aug 1999 17:41: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29907 invoked from network); 25 Aug 1999 17:41:18 -0000 Received: from caip.rutgers.edu (128.6.236.10) by egcs.cygnus.com with SMTP; 25 Aug 1999 17:41:18 -0000 Received: (from ghazi@localhost) by caip.rutgers.edu (8.9.3/8.9.3) id NAA26168; Wed, 25 Aug 1999 13:41:14 -0400 (EDT) Date: Wed, 25 Aug 1999 13:41:14 -0400 (EDT) From: "Kaveh R. Ghazi" Message-Id: <199908251741.NAA26168@caip.rutgers.edu> To: beyerj@sgi.com, gcc@gcc.gnu.org Subject: Re: printf format string > From: James Beyer > > What is the expected output if an argument does not have the > appropriate types for the string format specified? > > Is the argument just cast into the correct format, with casting rules > applied? Or is the output undefined in some cases? > > This seems like it may be implementation dependent. > > james Try using gcc -Wformat (or -Wall) to find at compile time the places where problems might occur. -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions From gcc-return-9503-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 18:26:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7317 invoked by alias); 25 Aug 1999 18:26:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7201 invoked from network); 25 Aug 1999 18:26:34 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 25 Aug 1999 18:26:34 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA01625; Wed, 25 Aug 1999 11:26:28 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id LAA03145; Wed, 25 Aug 1999 11:26:28 -0700 (PDT) Date: Wed, 25 Aug 1999 11:26:28 -0700 (PDT) Message-Id: <199908251826.LAA03145@kankakee.wrs.com> To: gcc@gcc.gnu.org, imarkov@cs.ucla.edu Subject: Re: Q: porting call_debugger() to g++ > Date: Tue, 24 Aug 1999 19:05:25 -0700 > From: Igor Markov > it's probably not a purely gcc question, but related. This has about 0 to do with gcc. If anything this is a UNIX question, a /proc question, and OS question, or maybe even a gdb question. Please learn what this list is for, and restrict your questions to things like the internal structure of gcc. We aren't here to hand hold you and teach you programming. From gcc-return-9504-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 20:03:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23588 invoked by alias); 25 Aug 1999 20:03:31 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23572 invoked from network); 25 Aug 1999 20:03:26 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 25 Aug 1999 20:03:26 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id QAA00581 for ; Wed, 25 Aug 1999 16:03:24 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (burley@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id QAA28368 for ; Wed, 25 Aug 1999 16:01:09 -0400 (EDT) Received: (qmail 28594 invoked by uid 500); 25 Aug 1999 19:58:03 -0000 Date: 25 Aug 1999 19:58:03 -0000 Message-ID: <19990825195803.28593.qmail@deer> To: jbuck@synopsys.com CC: jstern@citilink.com, jbuck@synopsys.com, gcc@gcc.gnu.org, george@moberg.com cc: craig@jcb-sc.com In-reply-to: <199908251541.IAA18967@atrus.synopsys.com> (message from Joe Buck on Wed, 25 Aug 99 8:41:34 PDT) Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <199908251541.IAA18967@atrus.synopsys.com> >Craig Burley, writing in the async interrupts debate. > >> Further, few people who say things like "lost in the noise" understand >> the fine distinctions between *types* of noise. In this case, I hope >> you don't consider synchronous bugs (bugs triggered by normal, >> straightline code) as in any way similar to asynchronous bugs. >> Excellent programmers can do a great job squashing the former >> kind -- very few understand how to even begin setting up a test >> bed that finds the latter (I could only *begin* to guess at that, >> myself, offhand). > >You use the techniques hardware engineers do. Digital oscilloscopes >to capture bus transactions; traces to capture every instruction executed, >stuff like that. I've been there. Me, too, but I consider that quite inadequate in larger-scale systems, such as the huge software systems we tend to build because it's so much easier than building them out of silicon. E.g. the GCC testsuite architecture would surely be inadequate if GCC was heavily into async stuff (built out of threads, used shared memory, whatever) -- for example, there'd need to be ways to test known hot-spots across a range of timings at which various async exceptions would be thrown at them. (Linux has this, of course -- the testsuite being a few million users on a wide variety of platforms. :) >> It's painful work getting this stuff right -- I remember spending *hours* >> just verifying that a particular shared-resource management scheme, >> implementing very simple primitives, was bullet-proof. > >Formal verification techniques have been used successfully here; for >instance, pretty much everyone doing multiprocessor hardware now does >formal verification for their cache coherency protocol. But these >techniques need some skill to use. Indeed, and, back in 1980 or so, when I was doing that particular project, we didn't have much in the way of software assists (and, stunningly to me looking back on it, I had basically zero experience with formal verification techniques anyway, though, it could be the case that I basically made them up as I went along, sufficient to meet the needs of that particular task). >I think that you're lumping two things together here: synchronous >exceptions are just branches, with a limited number of sources and >destinations. It's async exceptions that make life horrific. Indeed, though I am suspicious that even sync exceptions will be to the next decade what GOTOs were to the '70s, for roughly the same reasons. ;-) I have much to learn about what is exactly going on, but, having applied my budding "linguistic sensitivities" to what I already do know about synchronous exceptions, I don't see any clear winner of an answer to the problem of making sure people reading a chunk of code don't misunderstand what is going on. Eliminate sync exceptions from a language, and code that needs it might mislead programmers into thinking some paths are more important, or likely to be taken, than otherwise -- perhaps confusing them sufficiently to misunderstand the normal paths. Leave sync exceptions in, and, unless they're somehow linguistically restricted, readers might not see important potential branches -- which might be highly dependent on implementation- chosen types for variables, for example. (I.e. they're not lots better than `volatile'. Sure, in the context of C++, such linguistic problems might indeed be "lost in the noise", but that's a *lot* of noise, and I'm thinking in terms of the next several billion programmers to help write free software, not the few hundred or thousand that, today, can actually write C++ code that works *and* is readable. I'm not even sure I could supply the next ten thousand Fortran programmers with a proper language design that'd keep them from writing hard-to-debug code, though, since, so far, all I've gained much confidence about is what sorts of things *don't* work, not what new things might.) My best hope right now is to find some linguistic means to express sync- exception semantics at as high a level as possible, such that they can always be implemented as mere branches, then leave it up to optimization to make use of underlying support for exceptions, so readers always "see" the branches, including their relevance and importance. Mostly, though, I expect there isn't a real clean solution there, within the realm of the imperative programming model. Higher-level models presumably offer ways of escaping the mundane problems of all these exceptions, leaving the bigger problem of assuring programmers that their expressions will be implemented in finite time and space.... tq vm, (burley) From gcc-return-9505-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 20:03:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23825 invoked by alias); 25 Aug 1999 20:03:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23779 invoked from network); 25 Aug 1999 20:03:47 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 25 Aug 1999 20:03:47 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id QAA00604 for ; Wed, 25 Aug 1999 16:03:46 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (burley@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id QAA28516 for ; Wed, 25 Aug 1999 16:01:17 -0400 (EDT) Received: (qmail 28571 invoked by uid 500); 25 Aug 1999 19:37:18 -0000 Date: 25 Aug 1999 19:37:18 -0000 Message-ID: <19990825193718.28570.qmail@deer> To: jstern@citilink.com CC: gcc@gcc.gnu.org cc: craig@jcb-sc.com In-reply-to: <199908251710.MAA29103@foshay.citilink.com> (message from Josh Stern on Wed, 25 Aug 1999 12:10:54 -0500 (CDT)) Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads References: <199908251710.MAA29103@foshay.citilink.com> >Thanks Craig, for a long and thoughtful essay. >A couple of points of response. First off, some attention to the >rest of the thread would be required to understand the context of the >text quoted above. Indeed, I thought that might be the case, and called attention to that fact. >Part of that context was contained in the rest of the excerpted >post, which went on to describe a scheme for solving the problem >that I understood to be proposed by Joe: a) preserving the >legacy malloc() interface and b) avoiding even the possibility of >a memory leak in the presence of asynchronous exceptions. > >A couple of people, including you, have jumped on the word >choice "lost in the noise", but nobody seemed to object to the >argument that one could, after all, design a malloc that didn't >have the possibility of leaking in the presence of asynchronous >exceptions. My main concern is to reinforce resistance among GCC developers (and, for that matter, developers of *any* system upon which other systems are deployed) against accepting designs and/or implementations that have windows such as illustrated by that sample code. (Or, for that matter, accepting new features that expose such windows to programmers on the theory that "programmers should know better" -- but that gets further into my other controversial stances, such as wanting compiler defaults that favor stability and predictability, rather than performance.) >Clearly, I am not saying that the time window is lost in the noise, >but rather that the *combination* of the time window for a signal >at just that juncture, with a signal that is a case to throw(), >with a one-time memory leak (of small size - otherwise make use >of the other interface), with an architecture that isn't reclaiming >the memory through other means after such a throw - all of this >combined is less likely to cause a visible performance problem >in practice than say, a bug due to a compiler error. Perhaps >you disagree with that, but at least please disagree with my >actual opinion. I'm not sure I disagree with that anyway. I missed that you were limiting your commentary to performance issues -- sorry about that. >You've really raised the stakes in your commentary - talking about >missile systems and the like. >The idea that designing exception safe classes makes [...] >their use safe in the presence of exceptions, independently >of a context, is, I think, an illusion. [...] >Well I agree with you - at the level of stakes you are talking >about, most programs and programmers are broken. However, I may >have some differences regarding assessment of where the greatest risks >originate. FWIW, I think we agree about that, though you probably have more experience/expertise than I do. My raising the missile-systems issue was just an extreme example to illustrate the general thrust of my post: GCC developers should *never* accept a less-than-robust design for code generation. That's because GCC generates code for projects ranging from games to, if not missile systems, radiation-therapy machines and the like. So GCC developers are *fundamentally* incapable of assessing risks vis-a-vis code-generation issues, since they have, by definition, no information as to how any given use of GCC will be made, vis-a-vis the pertinent risks. It seems you weren't proposing such a design be accepted, in which case I definitely spoke out of turn. Sorry! tq vm, (burley) From gcc-return-9506-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 20:29:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27473 invoked by alias); 25 Aug 1999 20:28:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27389 invoked from network); 25 Aug 1999 20:28:35 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 25 Aug 1999 20:28:35 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA17428; Wed, 25 Aug 1999 13:27:47 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id NAA03373; Wed, 25 Aug 1999 13:27:46 -0700 (PDT) Date: Wed, 25 Aug 1999 13:27:46 -0700 (PDT) Message-Id: <199908252027.NAA03373@kankakee.wrs.com> To: law@cygnus.com, oliva@dcc.unicamp.br Subject: Re: Strange behaviour in C++... Cc: cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org > Date: Wed, 25 Aug 1999 11:30:09 -0600 > From: Jeffrey A Law > Just a note, thunks may be on their way out. I'm hearing more and > more people talk about the evils of thunks, particularly for high > end processors. Forget about talk, talk is cheap. What I have _never_ seen, are real performance numbers for real applications and/or micro benchmarks, that show what the numbers are. A complete analysis would include stuff like -fhuge-objects as well, as well, as cleanup up stupid codegen around virtual calls before getting numbers. Just my $0.02. From gcc-return-9507-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 20:34:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29084 invoked by alias); 25 Aug 1999 20:34:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29004 invoked from network); 25 Aug 1999 20:33:56 -0000 Received: from serval.noc.ucla.edu (169.232.10.12) by egcs.cygnus.com with SMTP; 25 Aug 1999 20:33:56 -0000 Received: from cs.ucla.edu (ts40-16.wla.ts.ucla.edu [164.67.23.45]) by serval.noc.ucla.edu (8.9.1a/8.9.1) with ESMTP id NAA28743; Wed, 25 Aug 1999 13:33:54 -0700 (PDT) Message-ID: <37C453ED.E6E88978@cs.ucla.edu> Date: Wed, 25 Aug 1999 13:37:01 -0700 From: Igor Markov Organization: UCLA, Computer Science X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Re: Q: porting call_debugger() to g++ References: <199908251826.LAA03145@kankakee.wrs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Stump wrote: > > > Date: Tue, 24 Aug 1999 19:05:25 -0700 > > From: Igor Markov > > > it's probably not a purely gcc question, but related. > > This has about 0 to do with gcc. If anything this is a UNIX question, > a /proc question, and OS question, or maybe even a gdb question. Look, argv[0] is exactly the string I need. However, I cannot get it in a function. How to pass this string around in a generic way has nothing to do with /proc, the OS or gdb. > Please learn what this list is for, and restrict your questions to > things like the internal structure of gcc. > > We aren't here to hand hold you and teach you programming. I would appreciate if people who are not trying to help ignored this message, to save their own time. Cheers, Igor -- Igor Markov office: (310) 206-0179 http://vlsicad.cs.ucla.edu/~imarkov From gcc-return-9508-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 20:55:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3642 invoked by alias); 25 Aug 1999 20:54:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3557 invoked from network); 25 Aug 1999 20:54:42 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 25 Aug 1999 20:54:42 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id OAA06420; Wed, 25 Aug 1999 14:53:10 -0600 X-Mailer: exmh version 2.0.2 To: Igor Markov cc: gcc@gcc.gnu.org Subject: Re: Q: porting call_debugger() to g++ Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 25 Aug 1999 13:37:01 PDT. <37C453ED.E6E88978@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Aug 1999 14:53:10 -0600 Message-ID: <6417.935614390@upchuck.cygnus.com> From: Jeffrey A Law In message <37C453ED.E6E88978@cs.ucla.edu>you write: > > Please learn what this list is for, and restrict your questions to > > things like the internal structure of gcc. > > > > We aren't here to hand hold you and teach you programming. > > I would appreciate if people who are not trying to help > ignored this message, to save their own time. We would appreciate it if *you* took inappropriate posts elsewhere. This is a list for compiler developers, not random discussions about gdb, procfs, basics of C programming, etc etc. Please stay on topic. jeff From gcc-return-9509-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 21:04:12 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6258 invoked by alias); 25 Aug 1999 21:03: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6192 invoked from network); 25 Aug 1999 21:03:16 -0000 Received: from feith1.feith.com (192.251.93.1) by egcs.cygnus.com with SMTP; 25 Aug 1999 21:03:16 -0000 Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.9.1b+Sun/8.9.2) with ESMTP id RAA16321; Wed, 25 Aug 1999 17:03:09 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.9.1b+Sun/8.9.1) id RAA29281; Wed, 25 Aug 1999 17:03:07 -0400 (EDT) Date: Wed, 25 Aug 1999 17:03:07 -0400 (EDT) From: John Wehle Message-Id: <199908252103.RAA29281@jwlab.FEITH.COM> To: imarkov@cs.ucla.edu Cc: gcc@gcc.gnu.org Subject: Re: Q: porting call_debugger() to g++ Content-Type: text > Look, argv[0] is exactly the string I need. > However, I cannot get it in a function. > How to pass this string around in a generic way has nothing > to do with /proc, the OS or gdb. Unfortunately I'm not sure that it has anything to do with gcc design and implementation which is what this list is about. > I would appreciate if people who are not trying to help > ignored this message, to save their own time. In a way Mike was trying to help you by suggesting that your search for an answer regarding this issue is better spent elsewhere. There are other mailing lists and news groups which can probably be more helpful for this particular question. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | ------------------------------------------------------------------------- From gcc-return-9510-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 21:07:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7543 invoked by alias); 25 Aug 1999 21:07:06 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7458 invoked from network); 25 Aug 1999 21:06:56 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 25 Aug 1999 21:06:56 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id OAA25294; Wed, 25 Aug 1999 14:03:23 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id OAA11157; Wed, 25 Aug 1999 14:03:21 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id OAA24440; Wed, 25 Aug 1999 14:03:21 -0700 Message-Id: <199908252103.OAA24440@atrus.synopsys.com> Subject: Re: Strange behaviour in C++... To: mrs@wrs.com (Mike Stump) Date: Wed, 25 Aug 99 14:03:21 PDT Cc: law@cygnus.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org In-Reply-To: <199908252027.NAA03373@kankakee.wrs.com>; from "Mike Stump" at Aug 25, 99 1:27 pm X-Mailer: ELM [version 2.3 PL11] Jeff writes: > > Just a note, thunks may be on their way out. I'm hearing more and > > more people talk about the evils of thunks, particularly for high > > end processors. Mike Stump writes: > Forget about talk, talk is cheap. What I have _never_ seen, are real > performance numbers for real applications and/or micro benchmarks, > that show what the numbers are. I'd like to second Mike's comments. What you may be overlooking, Jeff, is that the vast, vast majority of C++ objects are plain single inheritance, which means that no thunks are needed and the non-thunks implementation needs twice as much data space for the virtual function tables. So it simply does not matter if thunks are slower, since thunks are rarely called. It is a time-space tradeoff where the excess time cost is rare. From gcc-return-9511-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 21:08:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8049 invoked by alias); 25 Aug 1999 21:08:15 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8009 invoked from network); 25 Aug 1999 21:08:05 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 25 Aug 1999 21:08:05 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA22696; Wed, 25 Aug 1999 14:08:02 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id OAA03522; Wed, 25 Aug 1999 14:08:02 -0700 (PDT) Date: Wed, 25 Aug 1999 14:08:02 -0700 (PDT) Message-Id: <199908252108.OAA03522@kankakee.wrs.com> To: gcc@gcc.gnu.org, imarkov@cs.ucla.edu Subject: Re: Q: porting call_debugger() to g++ > Date: Wed, 25 Aug 1999 13:37:01 -0700 > From: Igor Markov > Mike Stump wrote: > > > > > Date: Tue, 24 Aug 1999 19:05:25 -0700 > > > From: Igor Markov > > > > > it's probably not a purely gcc question, but related. > > > > This has about 0 to do with gcc. If anything this is a UNIX question, > > a /proc question, and OS question, or maybe even a gdb question. > Look, argv[0] is exactly the string I need. Look, there is nothing about argv in gcc. It is _not_ a compiler issue. It is a `how do I program' issue. These issues are _not_ for this list. We are not here to help you program, or learn programming. You can find answers to this issue in comp.lang.c, in the glibc or newlib groups, and a variety of other places. > However, I cannot get it in a function. > How to pass this string around in a generic way has nothing > to do with /proc, the OS or gdb. If you only knew what I knew, you would have understood why I said what I did. I was trying to point you in a clueful direction. I am sorry you didn't understand that or the general direction I was pointing. > > Please learn what this list is for, and restrict your questions to > > things like the internal structure of gcc. > > > > We aren't here to hand hold you and teach you programming. > > I would appreciate if people who are not trying to help > ignored this message, to save their own time. While you may think that you can use this list for asking any programming questions you want and in fact you may do that, doesn't mean that you are right. It is wrong of you to ask us to ignore your messages. This is our list, we use it for specific purposes. The way in which you want to use this list isn't one of the ways in which we want people to use it. From gcc-return-9512-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 22:01:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24714 invoked by alias); 25 Aug 1999 22:01:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24672 invoked from network); 25 Aug 1999 22:01:22 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 25 Aug 1999 22:01:22 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id PAA06704; Wed, 25 Aug 1999 15:58:42 -0600 X-Mailer: exmh version 2.0.2 To: Joe Buck cc: mrs@wrs.com (Mike Stump), oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Strange behaviour in C++... Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 25 Aug 1999 14:03:21 PDT. <199908252103.OAA24440@atrus.synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Aug 1999 15:58:42 -0600 Message-ID: <6701.935618322@upchuck.cygnus.com> From: Jeffrey A Law > Mike Stump writes: > > Forget about talk, talk is cheap. What I have _never_ seen, are real > > performance numbers for real applications and/or micro benchmarks, > > that show what the numbers are. > > I'd like to second Mike's comments. What you may be overlooking, Jeff, is > that the vast, vast majority of C++ objects are plain single inheritance, > which means that no thunks are needed and the non-thunks implementation > needs twice as much data space for the virtual function tables. So it > simply does not matter if thunks are slower, since thunks are rarely > called. It is a time-space tradeoff where the excess time cost is rare. I understand completely, and unfortunately I left out a few important details. Most importantly that there is a group working on a C++ ABI which (from my understanding) will not include thunks (due to the performance concerns). I don't think we want to burn a lot of time on thunks if there's a reasonable chance the C++ ABI will take a different direction. Hopefully the people involved in this project are reading this list & thread and will chime in, particularly if I've mis-stated what's happening and why. jeff From gcc-return-9513-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 22:13:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28955 invoked by alias); 25 Aug 1999 22:13:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28928 invoked from network); 25 Aug 1999 22:12:56 -0000 Received: from mail.switchco.com (root@199.190.187.52) by egcs.cygnus.com with SMTP; 25 Aug 1999 22:12:56 -0000 Received: from switchco.com (proteus.swithcho.com [199.190.187.45]) by mail.switchco.com (8.8.0/8.6.12) with ESMTP id RAA08998; Wed, 25 Aug 1999 17:11:29 -0400 Message-ID: <37C477AF.C07F4508@switchco.com> Date: Wed, 25 Aug 1999 18:09:35 -0500 From: Benjamin Scherrey Reply-To: scherrey@proteus-tech.com Organization: Proteus Technologies, Inc. X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: law@cygnus.com CC: gcc@gcc.gnu.org Subject: Re: Strange behaviour in C++... References: <6701.935618322@upchuck.cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'd like to know more about what this group is doing as a clean C++ ABI is of extreme interest to me (especially if its intended to help support multiple platforms and portability). Is there a mailing list or web page for this group? thanx & later, Ben Scherrey Jeffrey A Law wrote: > I understand completely, and unfortunately I left out a few important details. > Most importantly that there is a group working on a C++ ABI which (from my > understanding) will not include thunks (due to the performance concerns). > > I don't think we want to burn a lot of time on thunks if there's a reasonable > chance the C++ ABI will take a different direction. > > Hopefully the people involved in this project are reading this list & thread > and will chime in, particularly if I've mis-stated what's happening and why. > > jeff From gcc-return-9514-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 22:45:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6893 invoked by alias); 25 Aug 1999 22:45:46 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6867 invoked from network); 25 Aug 1999 22:45:44 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 25 Aug 1999 22:45:44 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id SAA29944 for ; Wed, 25 Aug 1999 18:45:42 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (root@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id SAA28371 for ; Wed, 25 Aug 1999 18:42:43 -0400 (EDT) Received: (qmail 29470 invoked by uid 500); 25 Aug 1999 22:41:45 -0000 Date: 25 Aug 1999 22:41:45 -0000 Message-ID: <19990825224145.29469.qmail@deer> To: gcc@gcc.gnu.org cc: craig@jcb-sc.com Subject: Bad change to gcc/f/ffe.texi Whoever made this change, please undo it -- it was incorrect. I meant "effects", in the sense of "implements". (The latter might be a better word choice, actually.) tq vm, (burley) diff -rcp2N -x CVS -x .cvsignore ../g77-e/gcc/f/ffe.texi egcs/gcc/f/ffe.texi *** ../g77-e/gcc/f/ffe.texi Mon Aug 9 04:11:10 1999 --- egcs/gcc/f/ffe.texi Wed Aug 25 18:35:18 1999 *************** except it also provides automatic conver *** 641,645 **** and ignoring of newline-related carriage returns. ! It also effects the ``pure visual'' model, by which is meant that a user viewing his code in a typical text editor --- 641,645 ---- and ignoring of newline-related carriage returns. ! It also affects the ``pure visual'' model, by which is meant that a user viewing his code in a typical text editor From gcc-return-9515-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 22:48:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7736 invoked by alias); 25 Aug 1999 22:47:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7683 invoked from network); 25 Aug 1999 22:47:55 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 25 Aug 1999 22:47:55 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id PAA04125; Wed, 25 Aug 1999 15:45:42 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id PAA11086; Wed, 25 Aug 1999 15:45:37 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id PAA26371; Wed, 25 Aug 1999 15:45:36 -0700 Message-Id: <199908252245.PAA26371@atrus.synopsys.com> Subject: Re: Strange behaviour in C++... To: law@cygnus.com Date: Wed, 25 Aug 99 15:45:36 PDT Cc: jbuck@synopsys.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org In-Reply-To: <6701.935618322@upchuck.cygnus.com>; from "Jeffrey A Law" at Aug 25, 99 3:58 pm X-Mailer: ELM [version 2.3 PL11] Jeff writes: > Most importantly that there is a group working on a C++ ABI which (from my > understanding) will not include thunks (due to the performance concerns). Really? I know that there is a patent concern (Microsoft has patented one approach to thunks, one that both Per Bothner and I apparently independently "invented" but a bit different from the one g++ now uses), but it is work-aroundable. I think that any claim of a performance concern should be backed up by benchmarks. > I don't think we want to burn a lot of time on thunks if there's a reasonable > chance the C++ ABI will take a different direction. I assume that this would be an ABI for Intel-like hardware? (I can't imagine an unqualified ABI for all platforms, I think it is too early). From gcc-return-9516-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 23:02:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13141 invoked by alias); 25 Aug 1999 23:02:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13074 invoked from network); 25 Aug 1999 23:02:11 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 25 Aug 1999 23:02:11 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id QAA07108; Wed, 25 Aug 1999 16:59:12 -0600 X-Mailer: exmh version 2.0.2 To: Joe Buck cc: mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Strange behaviour in C++... Reply-To: law@cygnus.com In-reply-to: Your message of Wed, 25 Aug 1999 15:45:36 PDT. <199908252245.PAA26371@atrus.synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Aug 1999 16:59:07 -0600 Message-ID: <7105.935621947@upchuck.cygnus.com> From: Jeffrey A Law In message <199908252245.PAA26371@atrus.synopsys.com>you write: > Really? I know that there is a patent concern (Microsoft has patented > one approach to thunks, one that both Per Bothner and I apparently > independently "invented" but a bit different from the one g++ now uses), > but it is work-aroundable. I'm not that wired into this group, but I'd be amazed if they are not aware of the micky-soft patents and dealing with them in an appropriate manner. These people have more than a clue. > I think that any claim of a performance concern should be backed up by > benchmarks. Well, if they define the standard, we'll probably want to go along with it. The ability to mix-n-match code between different compilers is a good thing ;-) > I assume that this would be an ABI for Intel-like hardware? (I can't > imagine an unqualified ABI for all platforms, I think it is too early). ia64. But most of the concepts behind the ABI apply to other architectures -- name mangling, vtable layouts, empty virtual baseclass opts, etc etc. jeff From gcc-return-9517-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 23:10:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15127 invoked by alias); 25 Aug 1999 23:10:15 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15030 invoked from network); 25 Aug 1999 23:09:59 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 25 Aug 1999 23:09:59 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id RAA07209; Wed, 25 Aug 1999 17:08:30 -0600 X-Mailer: exmh version 2.0.2 To: craig@jcb-sc.com cc: gcc@gcc.gnu.org Subject: Re: Bad change to gcc/f/ffe.texi Reply-To: law@cygnus.com In-reply-to: Your message of 25 Aug 1999 22:41:45 -0000. <19990825224145.29469.qmail@deer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Aug 1999 17:08:30 -0600 Message-ID: <7206.935622510@upchuck.cygnus.com> From: Jeffrey A Law In message <19990825224145.29469.qmail@deer>you write: > Whoever made this change, please undo it -- it was incorrect. I meant > "effects", in the sense of "implements". (The latter might be a better > word choice, actually.) How about choosing a completely different word so that this kind of confusion does not occur in the future. It's silly to have to constantly fix affects vs effects mis-usages. jeff From gcc-return-9518-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 23:12:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16066 invoked by alias); 25 Aug 1999 23:12:54 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15999 invoked from network); 25 Aug 1999 23:12:36 -0000 Received: from pele.santafe.edu (192.12.12.119) by egcs.cygnus.com with SMTP; 25 Aug 1999 23:12:36 -0000 Received: from wijiji.santafe.edu (wijiji [192.12.12.5]) by pele.santafe.edu (8.9.1/8.9.1) with ESMTP id RAA05431 for ; Wed, 25 Aug 1999 17:12:31 -0600 (MDT) Received: (from rms@localhost) by wijiji.santafe.edu (8.9.1b+Sun/8.9.1) id RAA09239; Wed, 25 Aug 1999 17:12:31 -0600 (MDT) Date: Wed, 25 Aug 1999 17:12:31 -0600 (MDT) Message-Id: <199908252312.RAA09239@wijiji.santafe.edu> X-Authentication-Warning: wijiji.santafe.edu: rms set sender to rms@gnu.org using -f From: Richard Stallman To: gcc@gcc.gnu.org Subject: [gaius@glam.ac.uk: GNU Modula-2 progress] Reply-to: rms@gnu.org Please get in touch with him so you and he can work together. ------- Start of forwarded message ------- Date: Tue, 24 Aug 99 22:50 BST From: Gaius Mulley To: rms@gnu.org Subject: GNU Modula-2 progress Content-Type: text Content-Length: 961 Hi, I'm sure that you are very busy so I'll keep this email brief (no need for a reply). Basically I thought I'd let you know that progress is being made connecting the front end of m2f (a GPL Modula-2 compiler) with the back end of gcc, to produce gm2 (GNU Modula-2). I'm using gcc-2.8.1 whilst developing. I've not touched the GCC sources, except the makefiles to include gm2 target. So in theory it should be straightforward to take the Modula-2 components and fit them onto a later version of gcc. I've been developing since July, and things are going fine. Pretty much all declarations are complete, but code generation is still at an early stage (function prologue/epilogue, simple becomes & expressions complete). It is a great feeling to interface some aspect of m2f to gcc and then see really tight code being emitted. All credit to gcc. In short I'm hooked! cheers Gaius - --- Gaius Mulley University of Glamorgan gaius@glam.ac.uk ------- End of forwarded message ------- From gcc-return-9519-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 23:13:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16332 invoked by alias); 25 Aug 1999 23:13:34 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16312 invoked from network); 25 Aug 1999 23:13:33 -0000 Received: from pele.santafe.edu (192.12.12.119) by egcs.cygnus.com with SMTP; 25 Aug 1999 23:13:33 -0000 Received: from wijiji.santafe.edu (wijiji [192.12.12.5]) by pele.santafe.edu (8.9.1/8.9.1) with ESMTP id RAA05636; Wed, 25 Aug 1999 17:13:31 -0600 (MDT) Received: (from rms@localhost) by wijiji.santafe.edu (8.9.1b+Sun/8.9.1) id RAA09329; Wed, 25 Aug 1999 17:13:31 -0600 (MDT) Date: Wed, 25 Aug 1999 17:13:31 -0600 (MDT) Message-Id: <199908252313.RAA09329@wijiji.santafe.edu> X-Authentication-Warning: wijiji.santafe.edu: rms set sender to rms@gnu.org using -f From: Richard Stallman To: cmetz@inner.net cc: gcc@gcc.gnu.org In-reply-to: <199908240541.FAA00429@inner.net> (message from Craig Metz on Tue, 24 Aug 1999 01:41:32 -0400) Subject: Re: noalias question Reply-to: rms@gnu.org References: <199908240541.FAA00429@inner.net> Note that 3rd is illegal because we stored there through pc, an char * and we are going to access it again at 3rd through a int *. It is fine (AFAIU) if you store a char though pc and access it as a char later. The point is that this is _hard_ (probably impossible in the general case) to detect for a compiler, so the compiler is allowed to assume that *pi does not change, since no accesses through an int * could have changed *pi. I remember this aspect of the ANSI spec, but I think that `char *' is an exception--I think that it can alias with anything, and compilers are supposed to take account of that. Could someone check the actual specification? The main problem is that illegal accesses like above are used al over the place, e.g. in memcpy() and its ilk to speed them up (so they work with longs, not char by char). Hold on a second. Are you talking about the way the code of memcpy is written inside of Glibc? How GCC compiles that should have no effect on callers of memcpy, unless the function is declared inline. Is it declared inline? GCC can inline-expand some block-copies; is that what you are talking about? Mostly harmless, but the resulting kernels on i586 don't boot because of code reordering of a memset() and setting a struct member that tells the booting kernel to initialize IDE intefaces ;-) I wrote the handling of inline block copies to use whole words because that is more efficient. But logically if a certain block copy is a byte-wise operation, it should be treated as a byte-wise operation for aliasing purposes. Any explicit call to memset in the user's code is nominally a function call, which means it could refer to any part of memory in any data type. Therefore, it is wrong to reorder memory references through an explicit call to memset, even if that call happens to be open-coded. Aliasing must be treated as a legitimate possibility. If this were fixed, would it entirely solve the problem? Do all the problem cases involve calls to memset and memcpy? If not, what other cases are concerned? From gcc-return-9520-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 23:35:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19956 invoked by alias); 25 Aug 1999 23:35:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19926 invoked from network); 25 Aug 1999 23:35:15 -0000 Received: from adsl-216-102-199-253.dsl.snfc21.pacbell.net (HELO magnus.bothner.com) (root@216.102.199.253) by egcs.cygnus.com with SMTP; 25 Aug 1999 23:35:15 -0000 Received: by bothner.com via sendmail from stdin id (Debian Smail3.2.0.102) for gcc@gcc.gnu.org; Wed, 25 Aug 1999 16:41:20 -0700 (PDT) To: gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Strange behaviour in C++... References: <6701.935618322@upchuck.cygnus.com> From: Per Bothner Date: 25 Aug 1999 16:41:19 -0700 In-Reply-To: Jeffrey A Law's message of "Wed, 25 Aug 1999 15:58:42 -0600" Message-ID: Lines: 59 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta14) (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii FWIW: Two years ago or so I worked out a design for multiple inheritance that might significantly reduce the incidence of non-zero adjustment and hence the need for thunk. The goal was an efficient way to implement Java interface calls, but it might also apply to C++ virtual inheritance of base classes with no instance fields. The thing to note in this context is that Java "interfaces" are basically abstract classes with no instance fields. The tradeoff is that Java's "interface inheritance" arguably supports the most useful "90%" of the need multiple inhertitance. A quick summary: Because there are no fields, we don't need to adjust any pointers to get at the fields - we can use the address of the entire object as the address of the sub-part for the base class. This is what Java does, and it simplifies a lot of things. However, there is still one complication: We need to get at the correct vtable for the base class, given a pointer to the entire object, even though the compiler does not know the class of the entire object. The traditional C++ solution is to embed extra vtable pointers in the object, but that of course is what we must avoid. So we need an efficient way to map from the pointer for the entire object to the vtable for the base class. This is clearly possible, given RTTI. However, we want to use a code sequence that is constant time and small enough that it can be inlined. I came up with a design using some extra indexing using helper tables; a relatively small part of the tables are built at link time, rather than compile time. (This means that if new classes are loaded dynamically using dlopen, then some tables may have to be changed.) I can dig up the write-up if someone wants to pursue this (it was posted to java-discuss a few months ago). In any case, I'm not sure the specific implementation would be suitable for C++. But the basic idea is simple and general: At link time compute a map (hash) that for any empty abstract class and any class that inherits from it can map a pointer to the implementing class to the abstract class vtable, *without* adding any per-object pointers beyond the existing shared vtable pointer. There are some down-sides to the concept: The main one is that calls to abstract empty classes take a few more instructions. On the other hand, we save an extra vtable pointer per object per abstract empty class it implements, plus we save useless per-object vbase pointers. We also seriously reduce the incidence of non-zero pointer adjustments, which reduces the overhead of thunks. Finally, we get increased ABI compatibility between C++ and Java: C++ code can call methods given a reference to a Java interface type, and we can have G++ treat it the same as a call given a reference to a C++ abstract empty class. Thus a Java inheritance tree *including* interface inheritance can be mapped to equivalent C++ classes. This provides further unication of the C++ and Java ABIs and object models, which helps simplify Java, G++, LibGcj, and Gdb. I'd love it if someone more knowledgable about C++ ABI needs could chew on this concept, and perhaps come up with something that works for C++ as well as Java. -- --Per Bothner bothner@pacbell.net per@bothner.com http://home.pacbell.net/bothner/ From gcc-return-9521-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Aug 25 23:58:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23912 invoked by alias); 25 Aug 1999 23:58:09 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23897 invoked from network); 25 Aug 1999 23:58:07 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 25 Aug 1999 23:58:07 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA26469; Wed, 25 Aug 1999 16:58:06 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id QAA03876; Wed, 25 Aug 1999 16:58:06 -0700 (PDT) Date: Wed, 25 Aug 1999 16:58:06 -0700 (PDT) Message-Id: <199908252358.QAA03876@kankakee.wrs.com> To: gaius@glam.ac.uk, gcc@gcc.gnu.org Subject: Re: [gaius@glam.ac.uk: GNU Modula-2 progress] rms wanted us to get in touch with you so we can coordinate getting the work you've been doing into the compiler. > Date: Tue, 24 Aug 99 22:50 BST > From: Gaius Mulley > To: rms@gnu.org > Basically I thought I'd let you know that progress is being made > connecting the front end of m2f (a GPL Modula-2 compiler) with the > back end of gcc, to produce gm2 (GNU Modula-2). I'm using gcc-2.8.1 > whilst developing. > So in theory it should be straightforward to take the Modula-2 > components and fit them onto a later version of gcc. Yes. It would be nice. As you get large functional stuff done, you may want to check out a cvs gcc tree and incorporate your work into that tree, test it out, and get it checked into gcc. That way, future gcc releases will have support for Modula 2. Please see http://gcc.gnu.org for details, in particular, see the assignment section, and the cvs section. You should also check out dejagnu, and add a testing subsystem for Modula-2 testcases. I would copy the old-deja.exp style testcases from g++ land. (Copying is bad, better to factor out common code, and make both use it.) I'd love to see support in gcc for more languages. From gcc-return-9522-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 00:02:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25422 invoked by alias); 26 Aug 1999 00:02:42 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25375 invoked from network); 26 Aug 1999 00:02:35 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 26 Aug 1999 00:02:35 -0000 Received: from marathon.synopsys.com (marathon.synopsys.com [146.225.100.41]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id RAA10205; Wed, 25 Aug 1999 17:00:16 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by marathon.synopsys.com (8.8.8/8.8.8) with SMTP id RAA12205; Wed, 25 Aug 1999 17:00:12 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id RAA27147; Wed, 25 Aug 1999 17:00:12 -0700 Message-Id: <199908260000.RAA27147@atrus.synopsys.com> Subject: Re: Strange behaviour in C++... To: law@cygnus.com Date: Wed, 25 Aug 99 17:00:11 PDT Cc: jbuck@synopsys.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org In-Reply-To: <7105.935621947@upchuck.cygnus.com>; from "Jeffrey A Law" at Aug 25, 99 4:59 pm X-Mailer: ELM [version 2.3 PL11] I wrote: > > Really? I know that there is a patent concern (Microsoft has patented > > one approach to thunks, one that both Per Bothner and I apparently > > independently "invented" but a bit different from the one g++ now uses), > > but it is work-aroundable. > I'm not that wired into this group, but I'd be amazed if they are not > aware of the micky-soft patents and dealing with them in an appropriate > manner. These people have more than a clue. I'm sure that they have a clue, which was why I was suspecting patent concerns. They certainly wouldn't want to mandate a standard that requires a Microsoft patent to be licensed! > > I think that any claim of a performance concern should be backed up by > > benchmarks. > Well, if they define the standard, we'll probably want to go along with it. Yes, of course, at least for the port where the standard applies. > > I assume that this would be an ABI for Intel-like hardware? (I can't > > imagine an unqualified ABI for all platforms, I think it is too early). > ia64. But most of the concepts behind the ABI apply to other architectures -- > name mangling, vtable layouts, empty virtual baseclass opts, etc etc. Ah, now I understand ... thunks might really cost on that architecture. However, it is far from a typical architecture, and what's optimal for it might be far from best for others. I will be annoyed, however, if only those who have signed the ia64 NDAs get to play in setting this standard, and then we are asked to use it for all the other ports. Not all the clueful people are in that position. From gcc-return-9523-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 00:07:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27841 invoked by alias); 26 Aug 1999 00:07:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27781 invoked from network); 26 Aug 1999 00:07:14 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by egcs.cygnus.com with SMTP; 26 Aug 1999 00:07:14 -0000 Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id UAA126286; Wed, 25 Aug 1999 20:07:02 -0400 Received: from marc.watson.ibm.com (marc.watson.ibm.com [9.2.176.11]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id UAA14990; Wed, 25 Aug 1999 20:07:02 -0400 Received: from localhost by marc.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA24616; Wed, 25 Aug 1999 20:07:00 -0400 Message-Id: <9908260007.AA24616@marc.watson.ibm.com> To: Joe Buck Cc: law@cygnus.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Strange behaviour in C++... In-Reply-To: Message from Joe Buck of "Wed, 25 Aug 1999 17:00:11 PDT." <199908260000.RAA27147@atrus.synopsys.com> Date: Wed, 25 Aug 1999 20:07:00 -0400 From: David Edelsohn Thunks are bad on most any advanced architecture because it involves branches to branches with almost no computation, so instruction pre-fetch never catches up. David From gcc-return-9524-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 00:42:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 258 invoked by alias); 26 Aug 1999 00:42:24 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 199 invoked from network); 26 Aug 1999 00:42:22 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 26 Aug 1999 00:42:22 -0000 Received: from marathon.synopsys.com (marathon.synopsys.com [146.225.100.41]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id RAA13708; Wed, 25 Aug 1999 17:40:03 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by marathon.synopsys.com (8.8.8/8.8.8) with SMTP id RAA16435; Wed, 25 Aug 1999 17:39:46 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id RAA27573; Wed, 25 Aug 1999 17:39:45 -0700 Message-Id: <199908260039.RAA27573@atrus.synopsys.com> Subject: Re: Strange behaviour in C++... To: dje@watson.ibm.com (David Edelsohn) Date: Wed, 25 Aug 99 17:39:45 PDT Cc: jbuck@synopsys.com, law@cygnus.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org In-Reply-To: <9908260007.AA24616@marc.watson.ibm.com>; from "David Edelsohn" at Aug 25, 99 8:07 pm X-Mailer: ELM [version 2.3 PL11] David Edelsohn writes: > Thunks are bad on most any advanced architecture because it > involves branches to branches with almost no computation, so instruction > pre-fetch never catches up. Yes, I understand this. However, C++ programmers very rarely use multiple inheritance (because it isn't that well designed in the language and generally more trouble than it is worth). Let's say that the penalty for a thunk is 20-30 cycles. It would still be better than the alternative, because without thunks you must pay, on every virtual function table, for the possibility that multiple inheritance is involved, and the offset that is added is zero in almost all cases (including many of the MI cases). The other thing that may be missed is that a single cache miss would be more expensive in most cases than this loss of instruction pre-fetch. From gcc-return-9525-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 01:10:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4696 invoked by alias); 26 Aug 1999 01:10:40 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4651 invoked from network); 26 Aug 1999 01:10:38 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 26 Aug 1999 01:10:38 -0000 Received: (qmail 1858 invoked by alias); 26 Aug 1999 01:10:29 -0000 Received: (qmail 1834 invoked from network); 26 Aug 1999 01:10:25 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 26 Aug 1999 01:10:25 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id CAA08642; Thu, 26 Aug 1999 02:09:48 +0100 From: Joern Rennecke Message-Id: <199908260109.CAA08642@phal.cygnus.co.uk> Subject: Re: Strange behaviour in C++... In-Reply-To: <9908260007.AA24616@marc.watson.ibm.com> from David Edelsohn at "Aug 25, 1999 8: 7: 0 pm" To: dje@watson.ibm.com (David Edelsohn) Date: Thu, 26 Aug 1999 02:09:48 +0100 (BST) Cc: jbuck@synopsys.COM, law@cygnus.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Thunks are bad on most any advanced architecture because it > involves branches to branches with almost no computation, so instruction > pre-fetch never catches up. Well, you only pay that price when you actually *have* a thunk in your critical path. And if a thunk gets used very frequently, a CPU with branch target buffer is likely to need no prefetch for the thunked function after the first call. Indeed, you might even see a speedup, because fewer instructions in the callers need to be fetched (and maybe even fewer insns need decoding if the btb contains some predecoding). From gcc-return-9526-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 01:11:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5455 invoked by alias); 26 Aug 1999 01:11:54 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5423 invoked from network); 26 Aug 1999 01:11:54 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 26 Aug 1999 01:11:54 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id SAA17166; Wed, 25 Aug 1999 18:11:38 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id SAA12341; Wed, 25 Aug 1999 18:11:38 -0700 To: Joe Buck Cc: law@cygnus.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Strange behaviour in C++... References: <199908260000.RAA27147@atrus.synopsys.com> From: Jason Merrill Date: 25 Aug 1999 18:11:38 -0700 In-Reply-To: Joe Buck's message of "Wed, 25 Aug 99 17:00:11 PDT" Message-ID: Lines: 29 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Joe Buck writes: >> > I assume that this would be an ABI for Intel-like hardware? (I can't >> > imagine an unqualified ABI for all platforms, I think it is too early). >> ia64. But most of the concepts behind the ABI apply to other >> architectures -- name mangling, vtable layouts, empty virtual baseclass >> opts, etc etc. > Ah, now I understand ... thunks might really cost on that architecture. > However, it is far from a typical architecture, and what's optimal for > it might be far from best for others. > I will be annoyed, however, if only those who have signed the ia64 NDAs > get to play in setting this standard, and then we are asked to use it for > all the other ports. Not all the clueful people are in that position. Participation does not require signing the NDAs; we only discuss non-NDA stuff at the meetings. If you'd like to get involved, send email to dehnert@sgi.com. We currently have representatives from SGI (who put it together), Sun, SCO, IBM, and EDG as well as g++ folk. The rationale for dropping thunks is that the vtable size increase is not thought to be as important as the performance impact of thunks. Virtual inheritance is actually fairly common, I'm told (mixins and whatnot). The performance impact of the adjustment is avoided by doing the adjustment on the callee side (or not, if it isn't needed). Jason From gcc-return-9527-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 01:18:17 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8621 invoked by alias); 26 Aug 1999 01:18:15 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8581 invoked from network); 26 Aug 1999 01:18:11 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 26 Aug 1999 01:18:11 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA06761; Wed, 25 Aug 1999 18:18:07 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id SAA03937; Wed, 25 Aug 1999 18:18:06 -0700 (PDT) Date: Wed, 25 Aug 1999 18:18:06 -0700 (PDT) Message-Id: <199908260118.SAA03937@kankakee.wrs.com> To: gcc@gcc.gnu.org, per@bothner.com Subject: Re: Strange behaviour in C++... > From: Per Bothner > Date: 25 Aug 1999 16:41:19 -0700 > FWIW: Two years ago or so I worked out a design for multiple > inheritance that might significantly reduce the incidence of > non-zero adjustment Sounds interesting. I looked at the subject line of everything you ever said in java-discuss, and didn't spot it. I tried ~ 10 keyword searches, didn't find it. The only think I wonder about is, is the added cost worth it? Do you have any performance numbers that show the savings? I find it extremely hard to predict the runtime cost of this design over the two status quo designs in a real system. My off the cuff guess is that objects should be `used' more often that created and the cost of your scheme is in the use part, while the savings in your scheme is in the create part. To me this seems backwards. We want create to be expensive, and use to be fast. Is your scheme faster in the use part than status quo? I would guess not. struct I: { foo() = 0; } struct O: I { foo() { } } currently we do: fetch I vbase pointer fetch vtbl pointer add fetch fn pointer [fetch offset, add in offset] indirect call I think your proposing: open code for lookup vtbl for this,I add fetch fn pointer [fetch offset, add in offset] indirect call From gcc-return-9528-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 01:47:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14276 invoked by alias); 26 Aug 1999 01:47:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14253 invoked from network); 26 Aug 1999 01:47:11 -0000 Received: from adsl-216-102-199-253.dsl.snfc21.pacbell.net (HELO magnus.bothner.com) (root@216.102.199.253) by egcs.cygnus.com with SMTP; 26 Aug 1999 01:47:11 -0000 Received: by bothner.com via sendmail from stdin id (Debian Smail3.2.0.102) for gcc@gcc.gnu.org; Wed, 25 Aug 1999 18:53:16 -0700 (PDT) To: gcc@gcc.gnu.org Subject: Re: Strange behaviour in C++... References: <199908260118.SAA03937@kankakee.wrs.com> From: Per Bothner Date: 25 Aug 1999 18:53:16 -0700 In-Reply-To: Mike Stump's message of "Wed, 25 Aug 1999 18:18:06 -0700 (PDT)" Message-ID: Lines: 356 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta14) (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mike Stump writes: > Sounds interesting. I looked at the subject line of everything you > ever said in java-discuss, and didn't spot it. I tried ~ 10 keyword > searches, didn't find it. I found a copy in my files. This may not be exactly what I posted. (I seem to remember doing some minor editing to fix typos etc.) It's appended at the end. > The only think I wonder about is, is the added cost worth it? Do you > have any performance numbers that show the savings? No, it's a paper design only. > I find it extremely hard to predict the runtime cost of this design > over the two status quo designs in a real system. Well, for Java using the extra vtables is probably not acceptable, as it would change many assumptions. A strict reading of the JVM spec requires a successful cast to not change an object. Thus the only practical alternative I can think of for Java seems to be some kind of cached lookup, which seems much worse; it loses big if the actual classes change much. (For Gcj we don't even do any caching at this time, which may explain some of Gcj's so-so performance.) Also, I think the extra cost is modest - assuming there are no holes in my logic! The macro for an "interface call" is LOOKUP_INTERFACE. CL is the class/vtable/rtti structure of the actual "this" instance; the IFACE and IMETHODINDEX parameters are compile-time constants. > My off the cuff guess is that > objects should be `used' more often that created and the cost of your > scheme is in the use part, while the savings in your scheme is in the > create part. But using less (data) memory also has speed advantages. That is certainly obvious if you use a copying garbage collector ... Here is my old design sketch: /*** CLASS MEMBERHSIP TESTING ***/ /* The depth of a class is how many "extends" it is removed from Object. Thus the depth of java.lang.Object is 0, but the depth of javio.ioFilterOutputStream is 2. Depth is defined for regular classes and array classes, but not primitives types or interfaces. */ #define CLASS_DEPTH(CL) ((CL)->ui.cls.depth) // We can do class member testing in constant time adding in each class // using a small extra table of all the ancestor classes. // (This trick is relatively old.) // In Kaffe it makes sense to incorporate this table in the dispatchTable. // Note also we do not need to include the java.lang.Object in the table // of ancestors, since it is redundant. // If we order this table from current classes down by decreasing depth, // we can combine the ancestors table with the pointer to the actual classs. typedef void *methodptr; struct _dispatchTable { Class ancestors[CLASS_DEPTH(THIS_CLASS)-1]; methodptr method[...]; }; #define OBJECT_CLASS(OBJ) ((OBJ)->dtable->ancestors[0]) #define OBJECT_INSTANCEOF_CLASS(OBJ, CLS) \ CLASS_SUBCLASS_OF(OBJECT_CLASS(OBJ), CLS) #define CLASS_SUBCLASS_OF(OCLS, CLS) \ ((CLS) == &ObjectClass \ || ((CLASS_DEPTH(OCLS) - CLASS_DEPTH(CLS) >= 0 \ && (OCLS)->dtable->ancestors[CLASS_DEPTH(OCLS) - CLASS_DEPTH(CLS)] \ == (CLS)))) // Notice that the two instances CLASS_DEPTH(OCLS) - CLASS_DEPTH(CLS) can be // combined to a single subtraction. // Note that CLS is normally constant, such the first test against ObjectClass // be normally be eliminated at compile-time. If we assume that CLASS_DEPTH is seldom more than 4, we can make an optimization, at the cost of a few extra words per class: struct _dispatchTable { Class clas; // If the CLASS_DEPTH is less than 4, allocate 4 words anyway. // The unused ones are NULLs. Class ancestors[MIN(CLASS_DEPTH(THIS_CLASS)-1, 4)]; methodptr method[...]; }; #define OBJECT_CLASS(OBJ) ((OBJ)->dtable->clas) #define CLASS_SUBCLASS_OF_FAST(OCLS, CLS) \ (OCLS)->dtable->ancestors[CLASS_DEPTH(CLS)-1] == (CLS)))) #define CLASS_SUBCLASS_OF(OCLS, CLS) \ ((CLS) == &ObjectClass \ || (CLASS_DEPTH(CLS) <= 4 ? CLASS_SUBCLASS_OF_FAST(OCLS, CLS) \ : (CLASS_DEPTH(OCLS) >= CLASS_DEPTH(CLS) \ && (OCLS)->dtable->ancestors[CLASS_DEPTH(CLS)-1] == (CLS)))) // This wins, because we normally know (at compile-time) the identify // of CLS and it CLASS_DEPTH. Hence CLASS_SUBCLASS_OF reduces (at // compile-time) to CLASS_SUBCLASS_OF_FAST. // Reference: N. Wirth: Reply to "type-extension type tests can be // performed in constant time". ACM TOPLAS 13(4):630, 1991. /*** INTERFACES TESTS AND CALLS ***/ // Doing (x instanceof I) and calls like (((I)x).method(...)) are more // difficult. This is because interfaces may be "multiple inherited". // Looked an tests can be done in constant time with single inheritance, // because we can associate a unique depth to each class and a unique // method index to each virtual index, and in a way that the tables are // compact. This is more difficult with multiple inheritance. // Here I propose a design which I think is fairly efficient // in both time (constant-time) and space. // We associate an index with each method declared in an interface. // For each interface, we ignore any inherited interfaces, sort the methods // by some well-defined citerium (which could be declaration order), // and assign indexes starting with 1 (zero is used for type tests). // We call this index the Interface Methods Index of the interface method. // Each superinterface of a class (i.e. each interface that the class // directly or indirectly implements) has a corresponding "Partial // Interface Dispatch Table" whose size is (number of methods + 1) words. // The first word is a pointer to the interface (i.e. the java.lang.Class // instance for that interface). The remaining words are pointers to the // actual methods that implement the methods declared in the interface, // in the order specified by the Interface Method Index of the previous // peragraph. // For each non-abstract class, we create a list of its superinterfaces // These are sorted by some criterium (alphabetical seems as good as any). // We then create the "Interface Dispatch Table" by concatenating all the // Partial Interface Dispatch Tables for each superinterface, in the // order given by the sort. // The problem now is to find the correct offset in the Interface // Dispatch Table so we select the correct Partial Interface Dispatch Table // that we are intersted in. Once we have that, invoking an interface // method just requires indexing with the Interface Method Index (known at // compile time) to get the correct method. Doing a type test (cast or // instanceof) is the same problem: Once we have a possible Partial // Interface Dispatch Table, we just compare the first element to see if // it matches the desired interface. // So how can we calculate the correct offset? Unfortunateky, we can't // do it at compile time. It depends on both the interface, and the // actual class of the receiver. Our solution is to keep a vector of // candiate offsets in each interface (the ioffsets table), and // in each class we have an index (the iindex) used to select the // correct offset from ioffsets. struct Class { ...; union { struct { /* Index into interface's imap. */ short iindex; short depth; /* pointer to vector of pointer to dispatch tables. */ methodptr **itable; } cls; struct { /* Index into actual class's itable. */ short *imap; } iface; } ui; }; #define CLASS_IINDEX(CL) ((CL)->ui.cls.iindex) #define CLASS_ITABLE(CL) ((CL)->ui.cls.itable) #define CLASS_IMAP(CL) ((CL)->ui.iface.imap) #define LOOKUP_INTERFACE(CL, IFACE, IMETODINDEX) \ (CLASS_ITABLE(CL)[CLASS_IMAP(IFACE)[CLASS_IINDEX(cl)]][IMETHODINDEX]) struct Class { ...; union { struct { /* Index into interface's imap. */ short iindex; short itable_length; /* Pointer to Interface Dispatch Table. */ methodptr *itable; } cls; struct { /* Offsets into actual class's itable. */ /* First element is the length. */ /* Negative values are unused. */ short *ioffsets; } iface; } ui; }; #define CLASS_IINDEX(CL) ((CL)->ui.cls.iindex) #define CLASS_ITABLE(CL) ((CL)->ui.cls.itable) #define CLASS_ITABLE_LENGTH(CL) ((CL)->ui.cls.itable_length) #define CLASS_IOFFSETS(CL) ((CL)->ui.iface.ioffsets) #define CLASS_IOFFSETS_LENGTH(CL) ((CL)->ui.iface.ioffsets[0]) The CLASS_ITABLE can be computed at compile-time, and statically allocated. The CLASS_IINDEX of a class, and the CLASS_IOFFSETS of an interface, have to be computed at link time. In the case of dynamic loading, this means run-time. As more classes are loaded, CLASS_IINDEX does not change, but the CLASS_IOFFSETS vector of an interface may need to get extended if new classes are loaded. The function find_iiface does this calculation. #define LOOKUP_INTERFACE(CL, IFACE, IMETODINDEX) \ (CLASS_ITABLE(CL)[CLASS_IOFFSETS(IFACE)[CLASS_IINDEX(CL)] + IMETHODINDEX]) static short null_offset[2] = { 1, 0 }; /* Calculate and return the CLASS_IINDEX for a new class. * IFACES is a vector of NUM interfaces that the class implements. * OFFSETS[J] (for 0<=J= num) goto found; if (i >= CLASS_IOFFSETS_LENGTH(ifaces[j])) continue; int ioffset = CLASS_IOFFSETS(ifaces[j])[i]; if (ioffset >= 0 && ioffset != offsets[j]) break; /* Nope - try next i. */ } } found: for (j = 0; ; j++) { int len = CLASS_IOFFSETS_LENGTH(ifaces[j]); if (i >= len) { /* FIXME - check off-by-one erors. Should len field be counted in len? */ int newlen = 2 * len; if (i >= newlen) newlen = i + 3; short *old_ioffsets = CLASS_IOFFSETS(ifaces[j]); short *new_ioffsets; if (old_ioffsets == null_offset) { new_ioffsets = [gc]malloc(newlen * sizeof(short)); new_ioffsets[0] = 1; new_ioffsets[1] = 0; } else { new_ioffsets = [gc]realloc(old_ioffsets, newlen*sizeof(short)); } new_ioffsets[0] = newlen; while (len < newlen) new_ioffsets[len++] = -1; CLASS_IOFFSETS(ifaces[j]) = new_ioffsets; } CLASS_IOFFSETS(ifaces[j])[i] = offsets[j]; } return i; } Checking that an object is an instance of a class that implements a given interface (i.e. OBJ instanceof IFACE) uses the same data structures, and is also constant time: #define OBJECT_INSTANCEOF_INTERFACE(OBJ, IFACE) \ CLASS_INSTANCEOF_INTERFACE(OBJECT_CLASS(OBJ), IFACE) #define CLASS_INSTANCEOF_INTERFACE(CL, IFACE) \ (CLASS_IINDEX(CL) <= CLASS_IOFFSETS_LENGTH(IFACE) \ && ({unsigned short __offset = CLASS_IOFFSETS(IFACE)[CLASS_IINDEX(CL)]; \ __offset < CLASS_ITABLE_LENGTH(CL) \ && CLASS_ITABLE(CL)[__offset]] == IFACE})) This requries three tests. The first two are just bounds tests. We can remove the first test if we ensure that there is no CLASS_IINDEX lonker than any CLASS_IOFFSETS_LENGTH. That imples that all the ioffsets table have to have the same length: That of the largest CLASS_IINDEX. Unused elements of ioffsets could be marked with -1 - that would be safe as long as the comparsion against CLASS_ITABLE_LENGTH(CL) is unsigned. Using that data from experiements with classes.zip, that would require a maximum of 14 bytes for 105 interfaces that do not share null_offset. In other words: fairly minor. More space can be saved by sharing ioffsets vectors that are indentical; by a more clever allaoction of iindex values; and by a more clever re-arrangement of the Partial Interface Dispatch Tables with the Interface Dispatch Tables. One complication is that if a new classes is added that requires longer ioffsets vectors, then the ioffsets of all interfaces have to be relocated. But this should have infrequently, and only when a new class is loaded. CLASS_INSTANCEOF_INTERFACE is unfortunately a trifle long to be inlined. // Related work: // Vitek, Horspool and Krall: ""Efficient Type Inclusion Tests". // OOPSLA 97. ACM SIGPLAN Notices 32(10:142. 1997. // Some of the same people are also behind Cacao, a fast JIT for Alpha. // See http://www.complang.tuwien.ac.at/java/cacao/. // Cacao uses "coloring": Each interface or interface is assign a unique // global index, rather like perfect hashing. This makes dispatch fast, // but the per-class lookup tables are not dense. (In my proposed design, // the per-class lookup tables are dense, but the per-interface // ioffset vectors may be sparse. However, the ioffsets vectors are // still small and there are fewer interfaces than classes (that implement // interfaces). How much space is saved, and if it is worth it, // is open.) // It seem slikely that there will be more interfaces and more classes // implemeting interfaces in JDK 1.1, and code based on it. For example, // JDK 1.2 has new collector interfaces (such as List) that may become // popular. // Some relevant papers (including overview) are available from University // of Geneva's Objects Systems Group // http://cuiwww.unige.ch/OSG/publications/index.html // Numbers: JDK 1.1.4 classes.zip 153 interfaces 1458 classes total 1145 classes implement 0 interfaces 153 classes implement 1 interface (directly or indirectly) 105 classes implement 2 interfaces (directly or indirectly) 39 classes implement 3 interfaces (directly or indirectly) 10 classes implement 4 interfaces (directly or indirectly) 5 classes implement 5 interfaces (directly or indirectly) 1 class (java.awt.AWTEventMulticaster) implements 12 interfaces 160 classes implement more than 1 interface A very simple-minded assignment of ioffsets yields a maximum length of 7 2-byte shorts. (We could use 1-byte elements of each ioffset table to save some space, but that might prevent classes that implement many interfaces with many methods. There are none such in classes.zip.) -- --Per Bothner bothner@pacbell.net per@bothner.com http://home.pacbell.net/bothner/ From gcc-return-9529-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 03:57:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30472 invoked by alias); 26 Aug 1999 03:57:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30450 invoked from network); 26 Aug 1999 03:57:44 -0000 Received: from mail.switchco.com (root@199.190.187.52) by egcs.cygnus.com with SMTP; 26 Aug 1999 03:57:44 -0000 Received: from switchco.com (proteus.swithcho.com [199.190.187.45]) by mail.switchco.com (8.8.0/8.6.12) with ESMTP id WAA09580; Wed, 25 Aug 1999 22:47:33 -0400 Message-ID: <37C4C677.33E86FDE@switchco.com> Date: Wed, 25 Aug 1999 23:45:43 -0500 From: Benjamin Scherrey Reply-To: scherrey@proteus-tech.com Organization: Proteus Technologies, Inc. X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Joe Buck CC: gcc@gcc.gnu.org Subject: Re: Strange behaviour in C++... References: <199908260039.RAA27573@atrus.synopsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I actually use MI on more occasions than I thought I would (and way more than most applications developers) but I still concur. Embedded in every competent OO-programmer's mind is that MI comes at a cost. The philosophy that Stroustrup embarked on, "you don't pay for what you don't use", is one of the single most important reasons that C++ has been so successful today and was able to win the hearts and minds of so many C coders when Objective-C could not. Virtual calls are expensive enough (and often overused as well). To add an additional cost because of the MI implementation, even when MI isn't being used is an unacceptable consequence. I don't mind paying the cost (especially speed vs. size) when I determine that MI is the correct solution. regards, Ben Scherrey PS: This isn't explicitly a vote for thunks, per se, but rather for the philosophy for which the thunk implementation seems to be a good supporting solution. I'd support the best implementation that keeps the philosophy intact. Joe Buck wrote: > Yes, I understand this. However, C++ programmers very rarely use multiple > inheritance (because it isn't that well designed in the language and > generally more trouble than it is worth). Let's say that the > penalty for a thunk is 20-30 cycles. It would still be better than the > alternative, because without thunks you must pay, on every virtual > function table, for the possibility that multiple inheritance is involved, > and the offset that is added is zero in almost all cases (including > many of the MI cases). From gcc-return-9530-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 04:01:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31578 invoked by alias); 26 Aug 1999 04:01: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31563 invoked from network); 26 Aug 1999 04:01:47 -0000 Received: from gateway.ntu.edu.sg (155.69.1.127) by egcs.cygnus.com with SMTP; 26 Aug 1999 04:01:47 -0000 Received: by gateway.ntu.edu.sg with Internet Mail Service (5.5.2448.0) id ; Thu, 26 Aug 1999 12:01:40 +0800 Message-ID: <147BBF8976F0D211888508002BA60B668332DD@mail8.ntu.edu.sg> From: #VEE VOON YEE# Reply-To: vyvee@singnet.com.sg To: "'gcc@gcc.gnu.org'" Subject: Update of the build status of GCC Date: Thu, 26 Aug 1999 12:01:43 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Hi GCC developers, I am a user of GCC. I am happy to inform you that I have just built 'gcc-2.95.1' successfully on an Origin 2000. The build status of the configuration has not yet been listed in the GCC build status page. The output of running /config.guess is: ----------------------------------------- mips-sgi-irix6.4 ----------------------------------------- By the way, - I made use of the native assembler and linker that come with Irix6.4. - no single line of the source code needed a change during the compilation. Thanks for the great compiler! Regards, Voon-Yee Vee From gcc-return-9531-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 05:34:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7156 invoked by alias); 26 Aug 1999 05:34:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7139 invoked from network); 26 Aug 1999 05:34:22 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 26 Aug 1999 05:34:22 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990826053421.XVYN20194.mail.rdc1.md.home.com@home.com> for ; Wed, 25 Aug 1999 22:34:21 -0700 Message-ID: <37C4D272.2277EBCA@home.com> Date: Thu, 26 Aug 1999 01:36:50 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Intersting C++ error message. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit skip-t.hh:44: warning: choosing `clone_ptr::operator FilterItrPart *()' over `clone_ptr::operator const FilterItrPart *() const' skip-t.hh:44: warning: for conversion from `clone_ptr' to `const FilterItrPart *' skip-t.hh:44: warning: because conversion sequence for the argument is better Doing so is harmless as the offending methods are. operator Class * () {return ptr;} operator const Class * () const {return ptr;} But, I would like to know: 1) Why does it chose the nonconst method over the const one? 2) Sense this is harmless is there any way to suppress the warning? - Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-9532-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 05:38:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8336 invoked by alias); 26 Aug 1999 05:37:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8320 invoked from network); 26 Aug 1999 05:37:57 -0000 Received: from dns.infol.it (212.210.127.11) by egcs.cygnus.com with SMTP; 26 Aug 1999 05:37:57 -0000 Received: from zoltan.unisuv.it (piombino-port21.infol.it [212.210.127.151]) by dns.infol.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id RJHX7QLG; Thu, 26 Aug 1999 07:36:34 +0200 Received: from cs.unipr.it (localhost [127.0.0.1]) by zoltan.unisuv.it (8.9.3/8.9.3) with ESMTP id HAA07851 for ; Thu, 26 Aug 1999 07:37:50 +0200 Message-ID: <37C4D2AE.26D989E5@cs.unipr.it> Date: Thu, 26 Aug 1999 07:37:50 +0200 From: Roberto Bagnara X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.11 i586) X-Accept-Language: en MIME-Version: 1.0 To: egcs@egcs.cygnus.com Subject: Why the diffs for egcs-19990824 are unavailable? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In other words, the links to the diffs in ftp://egcs.cygnus.com/pub/egcs/snapshots/index.html seem to be dangling. Cna somebody put the diffs online? Thanks a lot, Roberto -- Roberto Bagnara Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it From gcc-return-9533-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 05:42:23 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9299 invoked by alias); 26 Aug 1999 05:42:21 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9284 invoked from network); 26 Aug 1999 05:42:16 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by egcs.cygnus.com with SMTP; 26 Aug 1999 05:42:16 -0000 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3) with ESMTP id IAA13595 for ; Thu, 26 Aug 1999 08:42:12 +0300 (EETDST) Received: from stybba.ntc.nokia.com (stybba.ntc.nokia.com [131.228.178.21]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id IAA12645 for ; Thu, 26 Aug 1999 08:42:12 +0300 (EETDST) Received: from sirion.ntc.nokia.com (sirion.ntc.nokia.com [131.228.178.154]) by stybba.ntc.nokia.com (8.9.1a/8.9.1/Goodi) with ESMTP id IAA11830; Thu, 26 Aug 1999 08:42:10 +0300 (EET DST) Received: (from girod@localhost) by sirion.ntc.nokia.com (8.8.6 (PHNE_17190)/8.7.1) id IAA15695; Thu, 26 Aug 1999 08:42:09 +0300 (EETDST) To: gcc@gcc.gnu.org X-Attribution: MGi Subject: Re: Strange behaviour in C++... References: From: Marc Girod Date: 26 Aug 1999 08:42:08 +0300 In-Reply-To: Per Bothner's message of "25 Aug 1999 23:35:52 GMT" Message-ID: <1yn1vfm72n.fsf@sirion.ntc.nokia.com> Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.4 Hello Per! This is sweet to my ears: I have been having closely related ideas. Unfortunately I cannot claim to be knowledgeable about the C++ ABI, but I am interested. If somebody takes the challenge, I certainly want to contribute. Best Regards! Marc -- Marc Girod Hiomo 5/1 Voice: +358-9-511 23746 Nokia Telecommunications P.O. Box 320 Mobile: +358-40-569 7954 NWS/NMS/NMS for Data 00045 NOKIA Group Fax: +358-9-511 23580 Finland girod@shire.ntc.nokia.com From gcc-return-9534-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 05:50:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10504 invoked by alias); 26 Aug 1999 05:50:15 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10489 invoked from network); 26 Aug 1999 05:50:09 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 26 Aug 1999 05:50:09 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id XAA08274; Wed, 25 Aug 1999 23:48:55 -0600 X-Mailer: exmh version 2.0.2 To: Roberto Bagnara cc: egcs@egcs.cygnus.com Subject: Re: Why the diffs for egcs-19990824 are unavailable? Reply-To: law@cygnus.com In-reply-to: Your message of Thu, 26 Aug 1999 07:37:50 +0200. <37C4D2AE.26D989E5@cs.unipr.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Aug 1999 23:48:55 -0600 Message-ID: <8271.935646535@upchuck.cygnus.com> From: Jeffrey A Law In message <37C4D2AE.26D989E5@cs.unipr.it>you write: > > In other words, the links to the diffs in > > ftp://egcs.cygnus.com/pub/egcs/snapshots/index.html > > seem to be dangling. > Cna somebody put the diffs online? As mentioned in the 0824 announcement, there are no diffs for that snapshot. Diffs will return with the next snapshot. jeff From gcc-return-9535-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 08:01:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24183 invoked by alias); 26 Aug 1999 08:00:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24158 invoked from network); 26 Aug 1999 08:00:49 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 26 Aug 1999 08:00:49 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id BAA08577; Thu, 26 Aug 1999 01:59:47 -0600 X-Mailer: exmh version 2.0.2 To: Per Bothner cc: gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter Reply-To: law@cygnus.com In-reply-to: Your message of 24 Aug 1999 22:09:24 PDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Aug 1999 01:59:47 -0600 Message-ID: <8574.935654387@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > I don't think these statements are very relevant. Yes, the compiler > sometimes does such re-writing, but that is not a problem for a conservative > collectors as long as there is still a pointer somewhere that points to > the actual base of the object. And either you have a newly allocated > object that will be passed to someone, or it was an existing object > that was passed from somewhere (as an argument). In either case, you > would have a pointer to the base object somewhere. But this is precisely the problem. You allocate a hunk of memory and initially assign it to some variable. Let's call it "a". You then do a lot of indexing off "a" in a loop. The compiler may create a pointer outside of "a" and kill the pseudo which originally contained "a". If you do garbage collection you lose. ie, the compiler effectively does something like this: a = malloc (100) a -= 10 for ( ... ) a[10 + i] = whatever even though you wrote a = malloc (100) for ( ...) a[i] = whatever jeff From gcc-return-9536-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 10:28:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20586 invoked by alias); 26 Aug 1999 10:28:21 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20570 invoked from network); 26 Aug 1999 10:28:15 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 26 Aug 1999 10:28:14 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id GAA23999 for ; Thu, 26 Aug 1999 06:28:11 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (burley@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id GAA01064 for ; Thu, 26 Aug 1999 06:26:03 -0400 (EDT) Received: (qmail 30223 invoked by uid 500); 26 Aug 1999 02:31:43 -0000 Date: 26 Aug 1999 02:31:43 -0000 Message-ID: <19990826023143.30222.qmail@deer> To: law@cygnus.com CC: gcc@gcc.gnu.org cc: craig@jcb-sc.com In-reply-to: <7206.935622510@upchuck.cygnus.com> (message from Jeffrey A Law on Wed, 25 Aug 1999 17:08:30 -0600) Subject: Re: Bad change to gcc/f/ffe.texi References: <7206.935622510@upchuck.cygnus.com> > In message <19990825224145.29469.qmail@deer>you write: > > Whoever made this change, please undo it -- it was incorrect. I meant > > "effects", in the sense of "implements". (The latter might be a better > > word choice, actually.) >How about choosing a completely different word so that this kind of confusion >does not occur in the future. Do you mean something other than "implements" in this case, which I think would be fine (preferable, even), or did you mean generally, as a style issue? (Offhand, the latter strikes me as reasonable, if not done mindlessly.) If you mean a completely different word, feel free to suggest one! tq vm, (burley) From gcc-return-9537-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 12:24:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24370 invoked by alias); 26 Aug 1999 12:24:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24342 invoked from network); 26 Aug 1999 12:24:25 -0000 Received: from val.icsr.agh.edu.pl (149.156.99.7) by egcs.cygnus.com with SMTP; 26 Aug 1999 12:24:25 -0000 Received: from localhost (iskra@localhost) by val.icsr.agh.edu.pl (8.9.1/8.9.1) with ESMTP id OAA28033 for ; Thu, 26 Aug 1999 14:24:19 +0200 Date: Thu, 26 Aug 1999 14:24:19 +0200 (DFT) From: Kamil Iskra To: gcc@gcc.gnu.org Subject: Excessive stack usage on m68k - BUG? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII When comparing output of egcs-1.1.2 and gcc-2.95 for m68k, I noticed some strange differences. The target is m68k-amigaos, not currently in the baseline sources, but I checked with m68k-linux, and the results were similar. int main(void) { char a[5]; f(a); } On egcs-1.1.2, this generates: #NO_APP gcc2_compiled.: ___gnu_compiled_c: .text .even .globl _main _main: link a5,#-8 jbsr ___main pea a5@(-6) jbsr _f moveq #0,d0 unlk a5 rts 8-byte frame for 5-byte array. OK. Now, with gcc-2.95: #NO_APP gcc2_compiled.: ___gnu_compiled_c: .text .even .globl _main _main: link a5,#-16 jbsr ___main pea a5@(-16) jbsr _f moveq #0,d0 unlk a5 rts Why 16 bytes? Is this a bug? I would like to hear your opinion before I dive into this. I grepped through the ChangeLog and could not find anything suitable in m68k-specific changes. STACK_BOUNDARY is still 16 (bits) in gcc-2.95, just as it used to be. Regards, Kamil From gcc-return-9538-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 13:14:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11634 invoked by alias); 26 Aug 1999 13:14:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11613 invoked from network); 26 Aug 1999 13:14:30 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 26 Aug 1999 13:14:30 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id PAA10640; Thu, 26 Aug 1999 15:11:24 +0200 (MET DST) Date: Thu, 26 Aug 1999 15:11:27 +0200 (MET DST) From: Gerald Pfeifer To: craig@jcb-sc.com cc: gvwilson@interlog.com, gcc@gcc.gnu.org Subject: Re: case of G77 symbol tables In-Reply-To: <19990825142942.27494.qmail@deer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 25 Aug 1999 craig@jcb-sc.com wrote: > the comp.lang.fortran FAQ might be, or point to, a useful resource for > further info on language mixing. I just realized that we don't have a link to that FAQ from our FAQ at http://gcc.gnu.org/faq.html. Would you mind adding that to the other ones at the beginning of that page? Thanks, Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9539-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 13:21:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13081 invoked by alias); 26 Aug 1999 13:21:54 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13064 invoked from network); 26 Aug 1999 13:21:52 -0000 Received: from atlas.lure.u-psud.fr (193.55.24.209) by egcs.cygnus.com with SMTP; 26 Aug 1999 13:21:52 -0000 Received: from lure.u-psud.fr ([192.168.79.67]) by ariane.lure.u-psud.fr (MX V4.1 VAX) with SMTP; Thu, 26 Aug 1999 15:21:47 MET DST Message-ID: <37C53F6A.C99009BC@lure.u-psud.fr> Date: Thu, 26 Aug 1999 15:21:46 +0200 From: Gerard Flynn Organization: LURE/CNRS X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: craig@jcb-sc.com CC: gcc@gcc.gnu.org Subject: Re: Using g77 and gdb together References: <37C2A770.C55551C6@lure.u-psud.fr> <19990824144005.22174.qmail@deer> <37C2E6B1.8AED4A73@lure.u-psud.fr> <19990824211351.24295.qmail@deer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit craig@jcb-sc.com wrote: > >The total number of included lines is 14 so the difference doesn't correspond > >exactly but it's close. > > Yup, IIRC the lexer "assigns" what I think are called "master line numbers" > to things like switching from one source file to another. This might, > for example, ease the handling of files not ending with a newline (which > I used to hate as a coder, but have since realized are, according to "my" > new rules for good plaintext-file design, entirely legit, since the absence > of a final newline makes no difference in how a file is typically imaged). > > My recall of the lexer issues surrounding this is rather faint, and I'm > strongly resisting looking into it again. Especially since the existing > code sits squarely in the cross-hairs of the rewrite I was proposing (and > would like to complete at least part of, if only to ease moving tests > out of my test suite into the GCC/g77 testsuite -- that perhaps needs > more explanation than I'm willing to give at this time, suffice to say, > I've wanted a "stand-alone lexer", as well as subsequent phases, for > years now, independent of their potential utility in the rewrite of the > g77 front end). > > What I am thinking, though, is that the problems tracking line numbers > show up only when doing at least *two* levels of INCLUDE, rather than > just one. That might be enough to spur someone to do a little digging > and perhaps find an easier solution than I thought was necessary a > couple of years ago, or to just implement that. > > tq vm, (burley) Ok I think I've found a possible solution to the problem. The function ffelex_include_() in lex.c apparently manages a stack of included files and lexer states. Several variables are saved before parsing a new file and then restored afterwards. One of these is ffelex_linecount_current_ which is used indirectly by ffewhere_file_set() to set the value of the line_no field in the corresponding ffewhereLL_ structure. This field in turn enters into the calculation of the line number which ultimately gets sent to the code generation modules. I don't pretend to know how all of this is supposed to work. However I observed that in a file with only one level of INCLUDE in which debugging line symbols are correctly generated, that the ll->line_no field was being set to the global line number (I mean the total number of lines parsed to date, independently of the file organization.) But that this was not happening with 2 INCLUDE levels. It would be however if the ffelex_linecount_current_ variable were not saved and restored by ffelex_include_(). My "solution" therefore is simply to remove the following two lines in lex.c (gcc-2.95.1): line 1550: ffewhereLineNumber linecount_current = ffelex_linecount_current_; and line 1605: ffelex_linecount_current_ = linecount_current; I've tried this and so far everything seems to be working fine. I'm now able to debug a program with 2 levels of INCLUDE with no problems whatsoever (at least as far as following the source goes). It seems to me that it would really be worth the effort for someone who knows a lot more about g77 than I to check and see if this modifcation makes sense and isn't likely to cause other problems because it makes a night versus day improvement in debugging files with nested INCLUDE's. Gerard Flynn From gcc-return-9540-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 13:31:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14423 invoked by alias); 26 Aug 1999 13:31:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14399 invoked from network); 26 Aug 1999 13:30:58 -0000 Received: from jess.glam.ac.uk (193.63.147.97) by egcs.cygnus.com with SMTP; 26 Aug 1999 13:30:58 -0000 Received: from [193.63.150.65] (helo=ems2.glam.ac.uk) by jess.glam.ac.uk with esmtp (Exim 3.02 #1) id 11JzWQ-0002TH-00; Thu, 26 Aug 1999 14:24:54 +0100 Received: from floppsie (gmulle.comp.glam.ac.uk [193.63.130.52]) by ems2.glam.ac.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id RRFAXFS0; Thu, 26 Aug 1999 14:35:09 +0100 Received: by floppsie (Smail3.1.28.1 #12) id m11Jzca-000SS6C; Thu, 26 Aug 99 14:31 BST Message-Id: Date: Thu, 26 Aug 99 14:31 BST From: Gaius Mulley To: mrs@wrs.com CC: gcc@gcc.gnu.org In-reply-to: <199908252358.QAA03876@kankakee.wrs.com> (message from Mike Stump on Wed, 25 Aug 1999 16:58:06 -0700 (PDT)) Subject: Re: [gaius@glam.ac.uk: GNU Modula-2 progress] References: <199908252358.QAA03876@kankakee.wrs.com> > rms wanted us to get in touch with you so we can coordinate getting > the work you've been doing into the compiler. Many thanks for the hints on how to integrate Modula-2 changes into gcc - especially the URL and cvs info. Here is part of the message I've just sent to rms about who wrote m2f: Thanks for the reply, for my sins I wrote all the compiler modules and all the library modules expect two (see below). It is a fully functioning Modula-2 compiler which currently runs on Linux and generates 80[3456]86 code, 8086 and is32 (a research abstract machine processor). It generated GDB .stabs info and worked well with the emacs/gdb combination. On the plus side it allows declarations in any order - as per Wirth's definition and it also allows abstract types to be any type, not just a pointer type. It conforms to Programming in Modula-2 edition 2 by N. Wirth (albeit the library modules are different). On the downside the code generator of m2f could be improved. Thus one of the many attractions of linking the front end of m2f up to the gcc back end :-). There are two library modules which I didn't write and I shall rewrite these modules (or remove them) Sort.mod (quicksort and bubble sort - actually the compiler doesn't need these so it might be easier to rm it). Also FIO.mod the file system input output module, which to keep things clean I'll take it out and write an alterative module blind following the guidelines in the emacs info system (using dynamic memory and different algorithms/approaches). Currently the all the library modules are not held by GPL but after this work they could be under GPL if you wish? I'm very keen for as much to be under GPL as possible. Any advice? Is this the right thing to do? I've signed a GNU registration form 3 years ago when I submitted some changes to gdb and binutils. Do I need to sign another for m2f/gcc ? cheers Gaius URL: http://floppsie.comp.glam.ac.uk click on Modula-2 and m2f under "Scratching an itch" From gcc-return-9541-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 14:04:12 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21123 invoked by alias); 26 Aug 1999 14:04:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21093 invoked from network); 26 Aug 1999 14:04:05 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 26 Aug 1999 14:04:05 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id 8DE0932D0E; Thu, 26 Aug 1999 16:03:37 +0200 (MEST) Received: from Wotan.suse.de (Wotan.suse.de [10.10.0.1]) by Galois.suse.de (Postfix) with ESMTP id A456467A8; Thu, 26 Aug 1999 16:03:33 +0200 (MEST) Received: from hawking.suse.de (Hawking.suse.de [10.10.0.89]) by Wotan.suse.de (Postfix) with ESMTP id 46C907F90; Thu, 26 Aug 1999 16:03:30 +0200 (MEST) Received: (from schwab@localhost) by hawking.suse.de (8.9.3/8.9.3) id QAA30952; Thu, 26 Aug 1999 16:03:28 +0200 To: Kamil Iskra Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: Excessive stack usage on m68k - BUG? References: X-Yow: Go on, EMOTE! I was RAISED on thought balloons!! From: Andreas Schwab Date: 26 Aug 1999 16:03:27 +0200 In-Reply-To: Kamil Iskra's message of "Thu, 26 Aug 1999 14:24:19 +0200 (DFT)" Message-ID: Lines: 56 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Kamil Iskra writes: |> Now, with gcc-2.95: |> |> #NO_APP |> gcc2_compiled.: |> ___gnu_compiled_c: |> .text |> .even |> .globl _main |> _main: |> link a5,#-16 |> jbsr ___main |> pea a5@(-16) |> jbsr _f |> moveq #0,d0 |> unlk a5 |> rts |> |> Why 16 bytes? This is a generic bug in the backend: Thu Aug 26 16:00:17 1999 Andreas Schwab * function.c (assign_stack_temp_for_type): Fix change of Mar 5 for the fact that ALIGN is measured in bits, not bytes. Index: function.c =================================================================== RCS file: /egcs/carton/cvsfiles/egcs/gcc/function.c,v retrieving revision 1.98 diff -u -a -u -r1.98 function.c --- function.c 1999/08/24 12:04:54 1.98 +++ function.c 1999/08/26 14:00:02 @@ -674,11 +674,12 @@ So for requests which depended on the rounding of SIZE, we go ahead and round it now. We also make sure ALIGNMENT is at least BIGGEST_ALIGNMENT. */ - if (mode == BLKmode && align < (BIGGEST_ALIGNMENT / BITS_PER_UNIT)) + if (mode == BLKmode && align < BIGGEST_ALIGNMENT) abort(); p->slot = assign_stack_local (mode, - mode == BLKmode - ? CEIL_ROUND (size, align) : size, + (mode == BLKmode + ? CEIL_ROUND (size, align / BITS_PER_UNIT) + : size), align); p->align = align; -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg From gcc-return-9542-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 14:52:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26845 invoked by alias); 26 Aug 1999 14:52:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26815 invoked from network); 26 Aug 1999 14:52:06 -0000 Received: from adsl-216-102-199-253.dsl.snfc21.pacbell.net (HELO magnus.bothner.com) (root@216.102.199.253) by egcs.cygnus.com with SMTP; 26 Aug 1999 14:52:06 -0000 Received: by bothner.com via sendmail from stdin id (Debian Smail3.2.0.102) for gcc@gcc.gnu.org; Thu, 26 Aug 1999 07:58:12 -0700 (PDT) To: gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter References: <8574.935654387@upchuck.cygnus.com> From: Per Bothner Date: 26 Aug 1999 07:58:12 -0700 In-Reply-To: Jeffrey A Law's message of "Thu, 26 Aug 1999 01:59:47 -0600" Message-ID: Lines: 36 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta14) (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Jeffrey A Law writes: > But this is precisely the problem. ... > ie, the compiler effectively does something like this: > > a = malloc (100) > a -= 10 > for ( ... ) > a[10 + i] = whatever > > even though you wrote > > a = malloc (100) > for ( ...) > a[i] = whatever You misunderstand. I am in favor of using (say) "gcmalloc" to allocate gc'd objects. I am *against* having malloc become as a wrapper for gcmalloc. Plain malloc should allocate plain manually managed memory. So when I say malloc, I mean plain malloc, so there is no issue in your example. My rationale is that most applications will use lower-level libraries that are written to use plain non-gc'd memory. It serves no purpose, and intoduces some risk, for them to use gc'd memory. My other point is that if you are allocating a temporary buffer with such an easy-analyzable lifetime that you risk the compiler making it dead and thus causing it to be prematurely free; why then you don't need to use garbage collection for this buffer, and by using plain malloc you remove the risk from pointer unsafety. Again, it seems that "pointer unsafety" is a mostly hypothetical problem, *assuming* you don't replace all your mallocs by gcmalloc, or otherwise use gcmalloc when malloc is more appropriate. -- --Per Bothner bothner@pacbell.net per@bothner.com http://home.pacbell.net/bothner/ From gcc-return-9543-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 15:14:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30965 invoked by alias); 26 Aug 1999 15:14:29 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30946 invoked from network); 26 Aug 1999 15:14:23 -0000 Received: from tas15-atm.tampabay.rr.com (root@24.92.0.65) by egcs.cygnus.com with SMTP; 26 Aug 1999 15:14:23 -0000 Received: from dunamis.tampabay.rr.com (dt0f3n7b.tampabay.rr.com [24.92.179.123]) by tas15-atm.tampabay.rr.com (8.9.3/8.9.3) with ESMTP id LAA29493 for ; Thu, 26 Aug 1999 11:09:07 -0400 (EDT) Message-ID: <199908261116410910.003E1CCE@smtp-server.tampabay.rr.com> X-Mailer: Calypso Version 3.00.00.14 (2) Date: Thu, 26 Aug 1999 11:16:41 -0400 Reply-To: roy@idle.com From: "Jonathan Roy" To: gcc@gcc.gnu.org Subject: Configure/make problem Content-Type: text/plain; charset="us-ascii" roy@odin.gamesmatrix.com (40) % ls -l | grep gcc drwxr-xr-x 16 roy staff 1024 Aug 26 08:08 gcc-2.95.1/ drwxr-xr-x 7 roy staff 512 Aug 26 08:08 gccobj/ roy@odin.gamesmatrix.com (40) % cd gccobj/ roy@odin.gamesmatrix.com (41) % /home/roy/FTP/gcc-2.95.1/configure --prefix=/opt /tools/.packages/gcc-2.95.1 I run make and I get: roy@odin.gamesmatrix.com (43) % !make make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap rm -f needed-list; touch needed-list; \ for f in atexit calloc memchr memcmp memcpy memmove memset rename strchr strerror strrchr strstr strtol strtoul tmpnam vfprintf vprintf vfork waitpid bcmp bcopy bzero; do \ for g in asprintf.o mkstemps.o setenv.o sigsetmask.o vasprintf.o ; do \ case "$g" in \ *$f*) echo $g >> needed-list ;; \ esac; \ done; \ done echo argv.o choose-temp.o concat.o cplus-dem.o fdmatch.o fnmatch.o getopt.o getopt1.o getruntime.o hex.o floatformat.o objalloc.o obstack.o pexecute.o spaces.o splay-tree.o strerror.o strsignal.o xatexit.o xexit.o xmalloc.o xstrdup.o xstrerror.o > required-list make all-recursive Making all in intl Making all in lib Making all in makeinfo make: Fatal error: Don't know how to make target `../lib/system.h' Current working directory /home/roy/FTP/gccobj/texinfo/makeinfo *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /home/roy/FTP/gccobj/texinfo *** Error code 1 make: Fatal error: Command failed for target `all-recursive-am' Current working directory /home/roy/FTP/gccobj/texinfo *** Error code 1 make: Fatal error: Command failed for target `all-texinfo' I'm trying to compile it outside of the source tree just like the docs recommend. I've always just compiled it in-place in the source tree in the past with no problems. Thought I should point out this isn't working, although it's very possible I'm doing something wrong... Solaris 2.7 machine. -Jonathan --- Jonathan Roy - roy@idle.com - Idle Communications, Inc. From gcc-return-9544-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 15:46:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2544 invoked by alias); 26 Aug 1999 15:46:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2525 invoked from network); 26 Aug 1999 15:46:23 -0000 Received: from dire.bris.ac.uk (137.222.10.60) by egcs.cygnus.com with SMTP; 26 Aug 1999 15:46:23 -0000 Received: from cs.bris.ac.uk (actually host luna.cs.bris.ac.uk) by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Thu, 26 Aug 1999 16:46:13 +0100 Received: from acm.org (manao [137.222.102.67]) by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id QAA05801; Thu, 26 Aug 1999 16:45:02 +0100 (BST) Message-ID: <37C560FE.CEEF686D@acm.org> Date: Thu, 26 Aug 1999 16:45:02 +0100 From: Nathan Sidwell Reply-To: nathan@compsci.bristol.ac.uk X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Atkinson CC: gcc@gcc.gnu.org Subject: Re: Intersting C++ error message. References: <37C4D272.2277EBCA@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kevin Atkinson wrote: > > skip-t.hh:44: warning: choosing `clone_ptr::operator > FilterItrPart *()' over `clone_ptr::operator const > FilterItrPart *() const' > skip-t.hh:44: warning: for conversion from `clone_ptr' > to `const FilterItrPart *' > skip-t.hh:44: warning: because conversion sequence for the argument is > better Iif I recall, this overload is ambiguous under ANSI, bug gnu offers the above extension. if you use -pedantic-errors, it'll be thrown out. > Doing so is harmless as the offending methods are. > > operator Class * () {return ptr;} > operator const Class * () const {return ptr;} > > But, I would like to know: > > 1) Why does it chose the nonconst method over the const one? because that is an identity conversion, rather than qualification conversion. > 2) Sense this is harmless is there any way to suppress the warning? ANSI mandates us to give a diagnostic. nathan -- Dr Nathan Sidwell :: Computer Science Department :: Bristol University I have seen the death of PhotoShop -- it is called GIMP nathan@acm.org http://www.cs.bris.ac.uk/~nathan/ nathan@cs.bris.ac.uk From gcc-return-9545-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 17:12:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14871 invoked by alias); 26 Aug 1999 17:12:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14817 invoked from network); 26 Aug 1999 17:12:42 -0000 Received: from esperi.demon.co.uk (194.222.138.8) by egcs.cygnus.com with SMTP; 26 Aug 1999 17:12:42 -0000 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id HAA27065 for ; Thu, 26 Aug 1999 07:47:35 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id HAA17595; Thu, 26 Aug 1999 07:47:41 +0100 From: Nix MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14276.58121.373014.810857@loki.wkstn.nix> Date: Thu, 26 Aug 1999 07:47:37 +0100 (BST) To: gcc@gcc.gnu.org Subject: Compilation failure report: Edinburgh speech_tools library w/gcc-2.95.1 on i586-pc-linux-gnu X-Mailer: VM 6.72 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Under grammar/ngram of this speech synthesis tools library (available from http://www.cstr.ed.ac.uk/projects/speechtools.html) compilation fails with : loki:/usr/packages/speech_tools/1.1.1/grammar/ngram% g++ -c -fno-implicit-templates -fguiding-decls -fpermissive -march=i586 -mwide-multiply -pipe -fPIC -Wall -I../../include EST_Ngrammar.cc : In file included from EST_Ngrammar.cc:44: : ../../include/EST_Token.h: In method `int EST_Token::operator ==(const char *)': : ../../include/EST_Token.h:148: warning: choosing `EST_String::operator char *()' over `EST_String::operator const char *() const' : ../../include/EST_Token.h:148: warning: for conversion from `EST_String' to `const char *' : ../../include/EST_Token.h:148: warning: because conversion sequence for the argument is better : ../../include/EST_Token.h: In method `int EST_Token::operator !=(const char *)': : ../../include/EST_Token.h:150: warning: choosing `EST_String::operator char *()' over `EST_String::operator const char *() const' : ../../include/EST_Token.h:150: warning: for conversion from `EST_String' to `const char *' : ../../include/EST_Token.h:150: warning: because conversion sequence for the argument is better : EST_Ngrammar.cc:596: sorry, not implemented: initializer contains unrecognized tree code : EST_Ngrammar.cc: In method `bool EST_Ngrammar::oov_preprocess(const EST_String &, EST_String &, const EST_String &)': : EST_Ngrammar.cc:1081: warning: choosing `EST_String::operator char *()' over `EST_String::operator const char *() const' : EST_Ngrammar.cc:1081: warning: for conversion from `EST_String' to `const char *' : EST_Ngrammar.cc:1081: warning: because conversion sequence for the argument is better Of course, the `initializer contains unrecognized tree code' is the nasty part. Unfortunately I haven't yet stripped the code down to a minimal test case, but a limited selection of the associated definitions are : bool EST_Ngrammar::init_sparse_representation() : { : : if (vocab->length() <= 0) : { : cerr << "EST_Ngrammar: dense_representation requires explicit vocab" : << endl; : return false; : } : >> p_states = new EST_NgrammarState[(int)pow(vocab->length(),p_order-1)]; : : return (bool)(p_states != NULL); : } : The error occurs on the line highlighted with >>. The definitions of the types used here are enormous. If they're needed please ask or download the speech_tools yourself and look :) I'm not sure how I can get a tree dump in ASCII (and it's the tree that's being mis-generated here, I assume)... any hints? This is a regression against egcs-1.1.2. The error is gone in the latest snapshot; I'll have a look and try to work out which patches fixed it. -- '- I can't believe my room doesn't have Ethernet! Why wasn't it wired when the house was built? - The house was built in 1576.' --- Alex Kamilewicz on the Cambridge breed of `conference American'. From gcc-return-9546-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 17:18:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16873 invoked by alias); 26 Aug 1999 17:18:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16816 invoked from network); 26 Aug 1999 17:17:56 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 26 Aug 1999 17:17:56 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id NAA14685 for ; Thu, 26 Aug 1999 13:17:54 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (burley@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id NAA05791 for ; Thu, 26 Aug 1999 13:14:55 -0400 (EDT) Received: (qmail 1546 invoked by uid 500); 26 Aug 1999 17:07:26 -0000 Date: 26 Aug 1999 17:07:26 -0000 Message-ID: <19990826170726.1545.qmail@deer> To: pfeifer@dbai.tuwien.ac.at CC: gvwilson@interlog.com, gcc@gcc.gnu.org cc: craig@jcb-sc.com In-reply-to: (message from Gerald Pfeifer on Thu, 26 Aug 1999 15:11:27 +0200 (MET DST)) Subject: Re: case of G77 symbol tables References: >On 25 Aug 1999 craig@jcb-sc.com wrote: >> the comp.lang.fortran FAQ might be, or point to, a useful resource for >> further info on language mixing. > >I just realized that we don't have a link to that FAQ from our FAQ at >http://gcc.gnu.org/faq.html. > >Would you mind adding that to the other ones at the beginning of that >page? I'd love to, but I don't know where it lives. I do have something that might be the right URL, but it seems out of date, and I don't read comp.lang.fortran anymore: http://kumo.swcp.com/fortran/FAQ/ Someone more "in touch" with c.l.f should look into this and add the appropriate info. tq vm, (burley) From gcc-return-9547-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 17:41:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22854 invoked by alias); 26 Aug 1999 17:41:29 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22821 invoked from network); 26 Aug 1999 17:41:23 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 26 Aug 1999 17:41:23 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA15436; Thu, 26 Aug 1999 10:41:22 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id KAA12682; Thu, 26 Aug 1999 10:41:21 -0700 (PDT) Date: Thu, 26 Aug 1999 10:41:21 -0700 (PDT) Message-Id: <199908261741.KAA12682@kankakee.wrs.com> To: gaius@glam.ac.uk Subject: Re: [gaius@glam.ac.uk: GNU Modula-2 progress] Cc: gcc@gcc.gnu.org > Date: Thu, 26 Aug 99 14:31 BST > From: Gaius Mulley > To: mrs@wrs.com > CC: gcc@gcc.gnu.org > On the downside the code generator of m2f could be improved. > Thus one of the many attractions of linking the front end of > m2f up to the gcc back end :-). gcc's backend technology has a lot of nice beef in it. Also, the coverage is great. :-) > Currently the all the library modules are not held by GPL but after > this work they could be under GPL if you wish? Yeah, technically all code in gcc is copyright by the FSF, and this happens through the assignment process. > I've signed a GNU registration form 3 years ago when I submitted > some changes to gdb and binutils. Do I need to sign another for > m2f/gcc ? Yes, unless a reading of that form covers the current work. Most of the time, it won't. When I did mine, I researched the various options, and put in all the things I wanted it to cover, for then, and now (future). From gcc-return-9548-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 17:47:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25461 invoked by alias); 26 Aug 1999 17:47:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25441 invoked from network); 26 Aug 1999 17:47:50 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 26 Aug 1999 17:47:50 -0000 Received: from saturn.hollstein.net (rtl.cygnus.com [205.180.230.21]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA03289; Thu, 26 Aug 1999 10:47:38 -0700 (PDT) Received: (from manfred@localhost) by saturn.hollstein.net (8.9.3/8.9.3) id OAA25237; Thu, 26 Aug 1999 14:59:36 +0200 Date: Thu, 26 Aug 1999 14:59:36 +0200 (MEST) From: Manfred Hollstein To: takis@XFree86.org Cc: law@cygnus.com, gcc@gcc.gnu.org Subject: Re: RE:DGUX Unix - GCC-2.95.x In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14277.13711.207945.508407@saturn.hollstein.net> Reply-To: Manfred Hollstein Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Hi Takis, I can fully understand your emotions in that a previously working package suddenly stopped working simply due to a (probably not obvious) change in a totally different package. I recognized this myself, when the new cpp failed to pre-define some macros which the old one did and which I had been using in my WMGR.rc file generating framework for years... The reason behind this, which has been explained by Jeff Law as "To be ansi compliant", might not be acceptable to you, because your /lib/cpp doesn't complain about missing "i386" macros etc. But, as Jeff was pointing out, ANSI-C requires particular constraints for symbols polluting the global namespace; as such, it defines names starting with "__" as reserved - and reserved names are not allowed to start without "__". This means, your /lib/cpp isn't ANSI compliant. Since the C preprocessor (/lib/cpp) isn't defined (or required) by any standard at all (just consider --enable-c-cpplib), it is up to you (or any package maintainer relying on the existance of such a file) to provide a proper version. Looking at your email address, it seems you are working with the XFree consortium; please let me suggest that XFree's (and probably all newer X) release's imake config files will be fixed *not* to use macros like "i386". I know, since there are various non-compliant C compilers and preprocessors around, it might be necessary to change all those occurrences like #ifdef i386 ... into #if defined (__i386__) || defined (i386) ... It isn't the right solution to request some particular feature from the compiler, only because it has been misused in the past. l8er manfred On Fri, 20 August 1999, 00:28:01, takis@XFree86.org wrote: > > > Hello, > > On Thu, 19 Aug 1999, Jeffrey A Law wrote: > > > In message > you $> ite: > > Probably because your mail was so disjointed and unreadable that nobody > > wanted to bother to try and understand it. > > > > OK. I am sorry for this I did wrote it in a rush. > > > Certainly not on purpose. > > OK. > > > And I would *strongly* disagree that > > gcc-2.8.1 actually worked correctly on dgux. The dgux port is a > > complete and total mess. I considered trying to get the various fixes > > into gcc-2.95, but there were many things which were more important than > > the dgux port. > > > > How many DG/ux machines do you have in cygnus? I have done also the > gdb port, and I've been told that you dont have any DG/ux machines. > gcc-2.8.1 works in DG/ux ix86. Perhaps needs one-two more changes > than the one in GNU but after that it performs well. I am compiling > X11R6, All the GNU toolkit , KDE, and whatever. More than 600 MBs > binaries. Dont confuse the problems of gcc-2.8.1 to work in coordination > with the DG/ux as and produce dwarf-2 with the general functionality > of gcc. Only recently I found that QT-2.0.1 doesnt compile correctly > with gcc-2.8.1 (c++) That is the only real serious bug that I am aware. > Disassembling the .s files reveals the fix though. > > > > To be ansi compliant. > > OK. My problem is not that since the external cpp (xcpp) works ok. > (has almost all the features that I need). Only I cannot copy it in > the gcc-local-dir since it will overwrite the "hidden version of cpp" > Typically in DG/ux we make a dir , say gcc-dg-2.95, with all the files > of gcc inside ie, gcc,c++,g++, libgcc,libobjc, cc1, cc1plus, cc1obj, > specs, cpp, crt* files , and we copy this directory to the elink. > Then the DG/ux elink will arrange to point from there the tools > to the actual "user path". > What I am saying is that in gcc.2.8.1 there was only _one_ "hidden" > cpp , that was living inside there. So if you now introducing a > change it will be good to leave this feature alone and just make > a "hidden_cpp" (or what ever other name you want) in gcc-local-dir. > If for some reason DG has arrange to access this cpp through its > elink the correct thing for the developer is not to change it and > then say to DGux users to contact DG (EMC) to change this particular > feature... > > > > imake should not depend on -Di386, it is an ANSI violation for > > the compiler to define -Di386. > > > ???... > > imake compiles with DGUX native cc. DG/UX cc will invoke cpp in the > gcc-local-dir (in more detail: the /lib/cpp that points through > the elink mechanism to an executable named cpp in the gcc-local-dir). > As the "hidden" 2.95 cpp misses features, cc will halt with errors. > If we had the sources of DG/ux we would be able of course to modify > the elink binaries in /usr/opt/sdk/bin to invoke the tools of our > choice. But I guess we dont have this option ... > > > Regards, > T. > > Manfred Hollstein Cygnus Solutions phone: +49-(0)7044-910079 Hindenburgstr. 13/1 mobile: +49-(0)170-3436257 75446 Wiernsheim, Germany fax: +49-(0)7044-910049 From gcc-return-9549-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 19:54:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24767 invoked by alias); 26 Aug 1999 19:54:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24739 invoked from network); 26 Aug 1999 19:54:41 -0000 Received: from thor.xraylith.wisc.edu (198.150.6.11) by egcs.cygnus.com with SMTP; 26 Aug 1999 19:54:41 -0000 Received: from mercury.xraylith.wisc.edu (mercury.xraylith.wisc.edu [128.104.182.221]) by thor.xraylith.wisc.edu (8.9.1a/8.9.1) with ESMTP id OAA14958; Thu, 26 Aug 1999 14:54:35 -0500 Received: from mercury.xraylith.wisc.edu (localhost [127.0.0.1]) by mercury.xraylith.wisc.edu (8.8.7/8.8.7) with ESMTP id OAA18146; Thu, 26 Aug 1999 14:54:09 -0500 Message-Id: <199908261954.OAA18146@mercury.xraylith.wisc.edu> To: craig@jcb-sc.com cc: gcc@gcc.gnu.org Subject: Re: case of G77 symbol tables In-Reply-To: Your message of "26 Aug 1999 17:07:26 -0000." <19990826170726.1545.qmail@deer> Date: Thu, 26 Aug 1999 14:54:09 -0500 From: Mumit Khan craig@jcb-sc.com writes: > >On 25 Aug 1999 craig@jcb-sc.com wrote: > >> the comp.lang.fortran FAQ might be, or point to, a useful resource for > >> further info on language mixing. > > > >I just realized that we don't have a link to that FAQ from our FAQ at > >http://gcc.gnu.org/faq.html. > > > >Would you mind adding that to the other ones at the beginning of that > >page? > > I'd love to, but I don't know where it lives. I do have something that > might be the right URL, but it seems out of date, and I don't read > comp.lang.fortran anymore: > > http://kumo.swcp.com/fortran/FAQ/ Please use http://www.fortran.com/fortran/ to refer to the Fortran Market instead of kumo.swcp.com. For FAQ's and other resources, see: http://www.fortran.com/fortran/info.html It has pointers to the FAQ and whole bunch of other stuff. However, I don't really know how useful these links are in reality. Regards, Mumit From gcc-return-9550-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 19:54:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24801 invoked by alias); 26 Aug 1999 19:54:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24754 invoked from network); 26 Aug 1999 19:54:46 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 26 Aug 1999 19:54:46 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA14183; Thu, 26 Aug 1999 12:54:46 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id MAA18819; Thu, 26 Aug 1999 12:54:45 -0700 Date: Thu, 26 Aug 1999 12:54:45 -0700 From: Richard Henderson To: Andreas Schwab Cc: Kamil Iskra , gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: Excessive stack usage on m68k - BUG? Message-ID: <19990826125445.B18739@cygnus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: ; from Andreas Schwab on Thu, Aug 26, 1999 at 04:03:27PM +0200 > Thu Aug 26 16:00:17 1999 Andreas Schwab > > * function.c (assign_stack_temp_for_type): Fix change of Mar 5 for > the fact that ALIGN is measured in bits, not bytes. This is ok. Please commit. r~ From gcc-return-9551-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 19:56:23 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25461 invoked by alias); 26 Aug 1999 19:56:12 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25380 invoked from network); 26 Aug 1999 19:56:01 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 26 Aug 1999 19:56:00 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id NAA04016; Thu, 26 Aug 1999 13:47:01 -0600 X-Mailer: exmh version 2.0.2 To: Gaius Mulley cc: mrs@wrs.com, gcc@gcc.gnu.org Subject: Re: [gaius@glam.ac.uk: GNU Modula-2 progress] Reply-To: law@cygnus.com In-reply-to: Your message of Thu, 26 Aug 1999 14:31:00 -0000. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Aug 1999 13:47:00 -0600 Message-ID: <4013.935696820@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > Is this the right thing to do? I've signed a GNU registration form > 3 years ago when I submitted some changes to gdb and binutils. Do > I need to sign another for m2f/gcc ? More likely than not you will need a new assignment since the default assignment for most people covers one set of changes to one particular program. I recommend you get a copy of "assign.future" which will allow you to assign all past and future work to a particular program (GNU Modula-2). There should be a copy on the web pages. See http://egcs.cygnus.com/contribute.html jeff From gcc-return-9552-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 20:23:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32631 invoked by alias); 26 Aug 1999 20:23:42 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32609 invoked from network); 26 Aug 1999 20:23:36 -0000 Received: from u197.cslab.tuwien.ac.at (HELO das.ist.org) (root@193.170.72.197) by egcs.cygnus.com with SMTP; 26 Aug 1999 20:23:36 -0000 Received: from ist.org (c11.dialin.tuwien.ac.at [192.35.243.21]) by das.ist.org (8.9.3/8.9.3) with ESMTP id XAA21682 for ; Thu, 26 Aug 1999 23:28:03 +0200 Message-ID: <37C5B17D.52AD1F9B@ist.org> Date: Thu, 26 Aug 1999 22:28:29 +0100 From: martin X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Problems with using DLL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! I am using gcc version egcs-2.91.60 in a cygwin Linux emulation shell (GNU bash version 2.02.1(2)-release (i586-pc-cygwin32)) under Windows95. I wrote a small program in C using a DLL (ML32I2.DLL; Mathlink for Windows) for several function calls. Since there were only Microsoft import libraries available (*.lib) I created my own gcc-style import library for the DLL using dlltool and a (selfmade) def-file. Gcc builds the program without any complaints (except for two warnings not related to my problem). When running the executable everything works fine, until AFTER executing the very last statement of the code (that is: printf("Exiting Now!\n"); ) I get an error message from Windows reading (I'm translating from German): a.exe caused error by page fault in module ML32I2.DLL at 0217:10005eaa. register: EAX=00000000 CS=0217 EIP=10005eaa EFLGS=00010246 EBX=0253fdf8 SS=021f ESP=0253fdcc EBP=0253fe00 ECX=005107ec DS=021f ESI=00416084 FS=4c97 EDX=00416084 ES=021f EDI=00000000 GS=0000 bytes at CS:EIP: 8b 07 50 8b 51 08 52 e8 2a b4 ff ff 83 c4 08 85 stack values: 815aabe4 0051031c 0253fe04 00000001 7fd10c3f bff798b7 815aa6c8 10003fb5 00416084 0253fdf8 0253fe00 00000000 004016ef 00000000 0253fe38 7fd013d6 I cannot gather much from this message (since my knowledge of DLLs and Windows is not very profound), but my questions are: What exactly does this message mean ? Can it be a coding error even when the error occurs after the last statement ? Is there a way of not deinitializing a DLL properly such that it causes an error on program exit ? Is it likely that the error has been caused by dlltool when creating the import library ? Is it likely that the error has been caused while linking with the import library ? I would be very glad about any advise. --Martin From gcc-return-9553-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 21:49:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14946 invoked by alias); 26 Aug 1999 21:49:31 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14929 invoked from network); 26 Aug 1999 21:49:28 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 26 Aug 1999 21:49:28 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA23489; Thu, 26 Aug 1999 14:49:26 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id OAA10851; Thu, 26 Aug 1999 14:49:26 -0700 To: nathan@cs.bris.ac.uk Cc: Kevin Atkinson , gcc@gcc.gnu.org Subject: Re: Intersting C++ error message. References: <37C4D272.2277EBCA@home.com> <37C560FE.CEEF686D@acm.org> From: Jason Merrill Date: 26 Aug 1999 14:49:26 -0700 In-Reply-To: Nathan Sidwell's message of "Thu, 26 Aug 1999 16:45:02 +0100" Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Nathan Sidwell writes: >> 2) Sense this is harmless is there any way to suppress the warning? > ANSI mandates us to give a diagnostic. No, it doesn't. I added that warning to warn people of potentially confusing results. I talked about a change a while back to avoid warning about probably-harmless cases like this one, but never implemented it. Jason From gcc-return-9554-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 21:59:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16333 invoked by alias); 26 Aug 1999 21:59:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16313 invoked from network); 26 Aug 1999 21:59:45 -0000 Received: from omzrelay03.mcit.com (199.249.19.245) by egcs.cygnus.com with SMTP; 26 Aug 1999 21:59:45 -0000 Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #38418) with ESMTP id <0FH300N2SEDW0B@firewall.mcit.com> for gcc@gcc.gnu.org; Thu, 26 Aug 1999 21:58:44 +0000 (GMT) Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121]) by omzrelay.mcit.com (8.8.7/) with ESMTP id VAA11965 for ; Thu, 26 Aug 1999 21:59:51 +0000 (GMT) Received: from CSP1571WK.mcit.com ([166.34.155.181]) by omzmta03.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19990826215831.LQFP24022@CSP1571WK.mcit.com> for ; Thu, 26 Aug 1999 21:58:31 +0000 Date: Thu, 26 Aug 1999 16:09:38 -0600 From: "Dane.Ruth" Subject: gcc 2.95 failure on AIX 4.2.1.0 To: gcc@gcc.gnu.org Message-id: <002701bef00f$b0044c80$b59b22a6@CSP1571WK.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal PLEASE HELP... I downloaded a executable version of gcc 2.95 from UCLA. It seems that the library stdio.h has a reference to standards.h that cannot be found. I compile the following program: +++TOP #include int main() { #ifdef __GNUC__ #ifdef __VERSION__ printf("%s\n",__VERSION__); #else printf("%s\n", "1"); #endif #endif exit(0); } +++END with the command: /usr/local/bin/gcc -o gccvers gccvers.c I get the following error message: In file include from gccvers.c:1: /usr/local/lib/gcc-lib/rs6000-ibm-aix4.2.0.0/2.95/include/stdio.h:31: standards.h: A file or directory in the path name does not exist. === Do I need a special complier switch or LIBPATH or something else???? ---- Thanks Dane Ruth (719) 535-1571 From gcc-return-9555-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 22:05:12 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17548 invoked by alias); 26 Aug 1999 22:05:07 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17532 invoked from network); 26 Aug 1999 22:05:03 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 26 Aug 1999 22:05:03 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990826220502.HQOB20194.mail.rdc1.md.home.com@home.com>; Thu, 26 Aug 1999 15:05:02 -0700 Message-ID: <37C5BAA9.B9FF6CEA@home.com> Date: Thu, 26 Aug 1999 18:07:37 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: nathan@cs.bris.ac.uk, gcc@gcc.gnu.org Subject: Re: Intersting C++ error message. References: <37C4D272.2277EBCA@home.com> <37C560FE.CEEF686D@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nathan Sidwell wrote: > > Kevin Atkinson wrote: > > > > skip-t.hh:44: warning: choosing `clone_ptr::operator > > FilterItrPart *()' over `clone_ptr::operator const > > FilterItrPart *() const' > > skip-t.hh:44: warning: for conversion from `clone_ptr' > > to `const FilterItrPart *' > > skip-t.hh:44: warning: because conversion sequence for the argument is > > better > Iif I recall, this overload is ambiguous under ANSI, bug gnu offers the > above extension. if you use -pedantic-errors, it'll be thrown out. Perhapes this is not the best place to ask: Why is it ambiguous, it is overloading based on the constness of the object, the "this" pointer. > > Doing so is harmless as the offending methods are. > > > > operator Class * () {return ptr;} > > operator const Class * () const {return ptr;} > > > > But, I would like to know: > > > > 1) Why does it chose the nonconst method over the const one? > because that is an identity conversion, rather than qualification > conversion. When I look at it agian it chooses the non const method becuase "this" is not const. So it did to the right thing. The warning would be clearer if it said: choosing ... instead of ... becuase "this" is non const, thus the conversion sequence for the argument is better. So how do I suppress the warning? -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-9556-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 22:19:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21027 invoked by alias); 26 Aug 1999 22:19:35 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21011 invoked from network); 26 Aug 1999 22:19:32 -0000 Received: from vss26.vss.fsi.com (HELO esds.vss.fsi.com) (199.217.137.156) by egcs.cygnus.com with SMTP; 26 Aug 1999 22:19:32 -0000 Received: from eos.vss.fsi.com (eos.vss.fsi.com [198.51.27.130]) by esds.vss.fsi.com (8.9.1a/8.9.1) with ESMTP id RAA02177; Thu, 26 Aug 1999 17:18:13 -0500 (CDT) Received: from localhost (ford@localhost) by eos.vss.fsi.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA05538; Thu, 26 Aug 1999 17:16:28 -0500 (CDT) X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Thu, 26 Aug 1999 17:16:28 -0500 (CDT) From: Brian Ford X-Sender: ford@eos To: rainer.dorsch@informatik.uni-stuttgart.de cc: gcc@gcc.gnu.org Subject: Re: Building binutils on Solaris In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 23 Aug 1999, Rainer Dorsch wrote: > The install/BUILD document says: > > Building a native compiler > > For a native build issue the command `make bootstrap'. This will build > the entire GCC system, which includes the following steps: > [...] > * Build target tools for use by the compiler such as gas, gld, and > binutils if they have been properly unpacked into the GCC source > tree. > > What does properly unpacked mean? > > I unpacked binutils on Solaris in gcc-2.95.1/binutils-2.9 (and made a link > from binutils to binutils-2.9) but no gas is build when I do make > bootstrap in the objdir. Even if I configure binutils before! > Properly unpacked means links to each of the individual directories under binutils-2.9 in gcc-2.95.1/ like (binutils, as, ld, ar, opcodes, etc.). -- Brian Ford Software Engineer Vital Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 From gcc-return-9557-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 22:25:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22924 invoked by alias); 26 Aug 1999 22:25:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22908 invoked from network); 26 Aug 1999 22:25:50 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by egcs.cygnus.com with SMTP; 26 Aug 1999 22:25:50 -0000 Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id SAA08878; Thu, 26 Aug 1999 18:25:41 -0400 Received: from marc.watson.ibm.com (marc.watson.ibm.com [9.2.176.11]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id SAA11430; Thu, 26 Aug 1999 18:25:41 -0400 Received: from localhost by marc.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA24628; Thu, 26 Aug 1999 18:25:41 -0400 Message-Id: <9908262225.AA24628@marc.watson.ibm.com> To: "Dane.Ruth" Cc: gcc@gcc.gnu.org Subject: Re: gcc 2.95 failure on AIX 4.2.1.0 In-Reply-To: Message from "Dane.Ruth" of "Thu, 26 Aug 1999 16:09:38 MDT." <002701bef00f$b0044c80$b59b22a6@CSP1571WK.mcit.com> Date: Thu, 26 Aug 1999 18:25:41 -0400 From: David Edelsohn You cannot mix GCC's cache of header files produced on on release of the OS (AIX 4.2.0) with system header files from another release (AIX 4.2.1). You need to rebuild the header file cache for your system. you may be able to blow away the header file cache and rebuild GCC using the installed GCC with the native headers to get a completely working version. David From gcc-return-9558-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 23:00:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26688 invoked by alias); 26 Aug 1999 22:59:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26654 invoked from network); 26 Aug 1999 22:59:44 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 26 Aug 1999 22:59:44 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA27947; Thu, 26 Aug 1999 15:58:49 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id PAA10543; Thu, 26 Aug 1999 15:58:48 -0700 To: Joe Buck Cc: dje@watson.ibm.com (David Edelsohn), law@cygnus.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: New vtable ABI (was Re: Strange behaviour in C++...) From: Jason Merrill Date: 26 Aug 1999 15:58:48 -0700 In-Reply-To: Joe Buck's message of "Wed, 25 Aug 99 17:39:45 PDT" Message-ID: Lines: 32 X-Mailer: Gnus v5.6.45/Emacs 20.3 I should point out here that the proposed mechanism is not the classic ARM vtable. In fact, it doesn't have any more space overhead for single inheritance code than thunks, and may have less for multiple inheritance code. It works like this: Rather than per-function offsets, we have per-target type offsets. These offsets (if any) are stored at a negative index from the vptr. When a derived class D overrides a virtual function F from a base class B, if no previously allocated offset slot can be reused, we add one to the beginning of the vtable(s) of the closest base(s) which are non-virtually derived from B. In the case of non-virtual inheritance, that would be D's vtable; in simple virtual inheritance, it would be B's. The vtables are written out in one large block, laid out like an object of the class, so if B is a non-virtual base of D, we can find the D vtable from the B vptr. D::f then recieves a B*, loads the offset from the vtable, and makes the adjustment to get a D*. The plan is to also have a non-adjusting vtable entry in D's vtable, so we don't have to do two adjustments to call D::f with a D*; the implementation of this is up to the compiler. I expect that for g++, we will do the adjustment in a thunk which just falls into the main function. The performance problems with classic thunks occur when the thunk is not close enough to the function it jumps to for a pc-relative branch. This cannot be avoided in certain cases of virtual inheritance, where a derived class must whip up a thunk for a new adjustment to a method it doesn't override. In this case, we will only ever have one thunk per function, so we don't even have to jump. Jason From gcc-return-9559-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 23:05:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28506 invoked by alias); 26 Aug 1999 23:04:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28491 invoked from network); 26 Aug 1999 23:04:58 -0000 Received: from omzrelay01.mcit.com (HELO alpha.mcit.com) (199.249.19.243) by egcs.cygnus.com with SMTP; 26 Aug 1999 23:04:58 -0000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #38416) with ESMTP id <0FH3008G2HFFV3@firewall.mcit.com> for gcc@gcc.gnu.org; Thu, 26 Aug 1999 23:04:27 +0000 (GMT) Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id XAA10587; Thu, 26 Aug 1999 23:03:10 +0000 (GMT) Received: from CSP1571WK.mcit.com ([166.34.155.181]) by omzmta03.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19990826230424.MKIR24022@CSP1571WK.mcit.com>; Thu, 26 Aug 1999 23:04:24 +0000 Date: Thu, 26 Aug 1999 17:15:37 -0600 From: "Dane.Ruth" Subject: RE: gcc 2.95 failure on AIX 4.2.1.0 In-reply-to: <9908262225.AA24628@marc.watson.ibm.com> To: David Edelsohn Cc: gcc@gcc.gnu.org Message-id: <000001bef018$e84e9ce0$b59b22a6@CSP1571WK.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Thanks.. Any one know where I may obtain executable version of gcc 2.95 or 2.95.1 running on AIX 4.2.1? ---- Dane Ruth (719) 535-1571 > -----Original Message----- > From: David Edelsohn [mailto:dje@watson.ibm.com] > Sent: Thursday, August 26, 1999 4:26 PM > To: Dane.Ruth > Cc: gcc@gcc.gnu.org > Subject: Re: gcc 2.95 failure on AIX 4.2.1.0 > > > You cannot mix GCC's cache of header files produced on on release > of the OS (AIX 4.2.0) with system header files from another release (AIX > 4.2.1). You need to rebuild the header file cache for your system. you > may be able to blow away the header file cache and rebuild GCC using the > installed GCC with the native headers to get a completely working > version. > > David > From gcc-return-9560-listarch-gcc=gcc.gnu.org@gcc.gnu.org Thu Aug 26 23:38:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32277 invoked by alias); 26 Aug 1999 23:38:42 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32246 invoked from network); 26 Aug 1999 23:38:39 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 26 Aug 1999 23:38:39 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA01163; Thu, 26 Aug 1999 16:38:24 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id QAA08789; Thu, 26 Aug 1999 16:38:24 -0700 To: Joe Buck Cc: dje@watson.ibm.com (David Edelsohn), law@cygnus.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: New vtable ABI (was Re: Strange behaviour in C++...) References: From: Jason Merrill Date: 26 Aug 1999 16:38:23 -0700 In-Reply-To: Jason Merrill's message of "26 Aug 1999 15:58:48 -0700" Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Jason Merrill writes: > In this case, we will only ever have one thunk per function Except in the case of covariant returns, I should say, where we will have one per return adjustment. But we know all necessary adjustments at the point of definition of the function, so they can all be within pc-relative branch range. Jason From gcc-return-9561-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 00:05:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6413 invoked by alias); 27 Aug 1999 00:05:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6372 invoked from network); 27 Aug 1999 00:05:17 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 27 Aug 1999 00:05:17 -0000 Received: from marathon.synopsys.com (marathon.synopsys.com [146.225.100.41]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id RAA26197; Thu, 26 Aug 1999 17:01:49 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by marathon.synopsys.com (8.8.8/8.8.8) with SMTP id RAA07124; Thu, 26 Aug 1999 17:01:43 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id RAA27894; Thu, 26 Aug 1999 17:01:43 -0700 Message-Id: <199908270001.RAA27894@atrus.synopsys.com> Subject: Re: New vtable ABI (was Re: Strange behaviour in C++...) To: jason@cygnus.com (Jason Merrill) Date: Thu, 26 Aug 99 17:01:43 PDT Cc: jbuck@synopsys.com, dje@watson.ibm.com, law@cygnus.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org In-Reply-To: ; from "Jason Merrill" at Aug 26, 99 3:58 pm X-Mailer: ELM [version 2.3 PL11] Jason writes: > I should point out here that the proposed mechanism is not the classic ARM > vtable. In fact, it doesn't have any more space overhead for single > inheritance code than thunks, and may have less for multiple inheritance > code. It works like this: [ details deleted ] Thanks, Jason, you've removed my objections. My problems were based on the classing scheme, where you have to store offsets for each vtable slot (space overhead) and add the offset during the call (time overhead). I don't quite grasp all of the details on first reading; diagrams would help, but it sounds elegant. (But then it seems that we'll at least temporarily have *three* vtable schemes, sigh). > Rather than per-function offsets, we have per-target type offsets. These > offsets (if any) are stored at a negative index from the vptr. Hmm ... RTTI is currently there, but RTTI takes a fixed # of slots so it's no problem. Joe From gcc-return-9562-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 00:13:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8285 invoked by alias); 27 Aug 1999 00:13:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8255 invoked from network); 27 Aug 1999 00:13:46 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 27 Aug 1999 00:13:46 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA03888; Thu, 26 Aug 1999 17:13:30 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id RAA01597; Thu, 26 Aug 1999 17:13:30 -0700 To: Joe Buck Cc: dje@watson.ibm.com, law@cygnus.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: New vtable ABI (was Re: Strange behaviour in C++...) References: <199908270001.RAA27894@atrus.synopsys.com> From: Jason Merrill Date: 26 Aug 1999 17:13:29 -0700 In-Reply-To: Joe Buck's message of "Thu, 26 Aug 99 17:01:43 PDT" Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Joe Buck writes: >> Rather than per-function offsets, we have per-target type offsets. These >> offsets (if any) are stored at a negative index from the vptr. > Hmm ... RTTI is currently there, but RTTI takes a fixed # of slots > so it's no problem. Actually, RTTI is currently at indices 0 and 1. It will probably make sense to move them to negative offsets in the new model, since COM wants the functions to start at offset 0. Jason From gcc-return-9563-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 00:26:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10316 invoked by alias); 27 Aug 1999 00:26:42 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10277 invoked from network); 27 Aug 1999 00:26:36 -0000 Received: from thor.xraylith.wisc.edu (198.150.6.11) by egcs.cygnus.com with SMTP; 27 Aug 1999 00:26:36 -0000 Received: from mercury.xraylith.wisc.edu (mercury.xraylith.wisc.edu [128.104.182.221]) by thor.xraylith.wisc.edu (8.9.1a/8.9.1) with ESMTP id TAA15775; Thu, 26 Aug 1999 19:26:32 -0500 Received: from mercury.xraylith.wisc.edu (localhost [127.0.0.1]) by mercury.xraylith.wisc.edu (8.8.7/8.8.7) with ESMTP id TAA19144; Thu, 26 Aug 1999 19:26:01 -0500 Message-Id: <199908270026.TAA19144@mercury.xraylith.wisc.edu> To: Jason Merrill cc: Joe Buck , dje@watson.ibm.com, law@cygnus.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: New vtable ABI (was Re: Strange behaviour in C++...) In-Reply-To: Your message of "26 Aug 1999 17:13:29 PDT." Date: Thu, 26 Aug 1999 19:26:01 -0500 From: Mumit Khan Jason Merrill writes: > > Actually, RTTI is currently at indices 0 and 1. It will probably make > sense to move them to negative offsets in the new model, since COM wants > the functions to start at offset 0. Makes very good sense. It really would stink to have to disable RTTI when using COM and its variants. Regards, Mumit From gcc-return-9564-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 01:52:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19950 invoked by alias); 27 Aug 1999 01:51:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19934 invoked from network); 27 Aug 1999 01:51:57 -0000 Received: from kanga.nttca.com (204.160.176.156) by egcs.cygnus.com with SMTP; 27 Aug 1999 01:51:57 -0000 Received: from ntta.com (dhcp-165.noc.cup.ndp.net [209.212.224.165]) by kanga.nttca.com (8.8.8/NTTCA/v1.0) with ESMTP id SAA07155 for ; Thu, 26 Aug 1999 18:51:56 -0700 (PDT) Message-ID: <37C5EF56.7EDCC341@ntta.com> Date: Thu, 26 Aug 1999 18:52:23 -0700 From: Jerin C Justin Organization: NTT America X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: bianries for HP-UX 10.10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Are there any binaries for gcc 2.8.1 for HP-UX 10.10. Regards Jerin From gcc-return-9565-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 05:54:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16758 invoked by alias); 27 Aug 1999 05:54: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16732 invoked from network); 27 Aug 1999 05:54:43 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 27 Aug 1999 05:54:42 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id XAA05725; Thu, 26 Aug 1999 23:46:15 -0600 X-Mailer: exmh version 2.0.2 To: craig@jcb-sc.com cc: gcc@gcc.gnu.org Subject: Re: Bad change to gcc/f/ffe.texi Reply-To: law@cygnus.com In-reply-to: Your message of 26 Aug 1999 02:31:43 -0000. <19990826023143.30222.qmail@deer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Aug 1999 23:46:15 -0600 Message-ID: <5722.935732775@upchuck.cygnus.com> From: Jeffrey A Law In message <19990826023143.30222.qmail@deer>you write: > Do you mean something other than "implements" in this case, which I > think would be fine (preferable, even), I meant to use a word other than "effects" or "affects" with people (myself included) often get wrong. If you're happy with "implements" in that context I'll happily change it. I'm not really qualified to make that decision since I do not understand what you're trying to say in that text. > or did you mean generally, as a style issue? That too. :-) If we can avoid affect/effect when there is a better word which isn't mis-used as often we probably should. If no better word exists, then we'll just be stuck with affect/effect. jeff From gcc-return-9566-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 06:21:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27632 invoked by alias); 27 Aug 1999 06:21:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27514 invoked from network); 27 Aug 1999 06:20:50 -0000 Received: from puma.cs.nthu.edu.tw (HELO puma.cs.nthu.edu.tw?) (140.114.79.125) by egcs.cygnus.com with SMTP; 27 Aug 1999 06:20:50 -0000 Received: from turtle1 (mozart.cs.nthu.edu.tw) by puma.cs.nthu.edu.tw (4.1/SMI-4.1) id AA04844; Fri, 27 Aug 99 14:20:57 CST From: =?big5?B?s6/EUKTJ?= To: Subject: Where can get documents (PDF or PS version)? Date: Fri, 27 Aug 1999 14:20:58 +0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 DQogICAgSGk6DQogICAgICBTb3JyeSB0byBpbnRlcnJ1cHQgeW91ciB3b3JrLg0KICAgICAgSSBj YW4gZ2V0IHRoZSBHTlUncyBtYW51YWwgZnJvbSBXZWIuDQogICAgIFdoZXJlIGNhbiBJIGdldCB0 aGUgIlVzaW5nIGFuZCBQb3J0aW5nIEdDQyIncyBkb2N1bWVudCAoUERGIG9yIFBTIHZlcnNpb24p Pw0KICAgICBUaGFua3MgeW91ciByZXBseSENCg0KDQoJCQkJCQlQcy4gQ2hlbg== From gcc-return-9567-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 06:23:23 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28765 invoked by alias); 27 Aug 1999 06:23:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28720 invoked from network); 27 Aug 1999 06:23:13 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 27 Aug 1999 06:23:13 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id AAA05978; Fri, 27 Aug 1999 00:14:40 -0600 X-Mailer: exmh version 2.0.2 To: Mark Klein cc: gcc@gcc.gnu.org Subject: Re: HARD_REGNO_MODE_OK on PA-RISC (revisited) Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 24 Aug 1999 21:56:31 PDT. <4.1.19990824214047.00ce42e0@garfield.dis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 00:14:40 -0600 Message-ID: <5975.935734480@upchuck.cygnus.com> From: Jeffrey A Law In message <4.1.19990824214047.00ce42e0@garfield.dis.com>you write: > At 08:37 PM 8/24/99 -0600, Jeffrey A Law wrote: > > >There is nothing wrong with requiring aligned registers, it is just > suboptimal. > > The original question had to do with long double which according to the ACD > must be aligned on a 128 bit boundary. This is what works for long double. > If I'm missing something else, please refresh my memory, as it has been > over four months since I looked at this. Adding additional alignment restrictions for wider types is certainly do-able. Note that the code in question has changed quite a bit recently in preparation for PA64 support. jeff From gcc-return-9568-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 07:21:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10390 invoked by alias); 27 Aug 1999 07:21:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10367 invoked from network); 27 Aug 1999 07:21:37 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 27 Aug 1999 07:21:37 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990827072135.MMMJ20194.mail.rdc1.md.home.com@home.com>; Fri, 27 Aug 1999 00:21:35 -0700 Message-ID: <37C63D20.3F912988@home.com> Date: Fri, 27 Aug 1999 03:24:16 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: Per Bothner CC: gcc@gcc.gnu.org, Jeffrey A Law Subject: Re: C++ Garbage Collecter References: <8574.935654387@upchuck.cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Per Bothner wrote: > Again, it seems that "pointer unsafety" is a mostly hypothetical problem, > *assuming* you don't replace all your mallocs by gcmalloc, or otherwise > use gcmalloc when malloc is more appropriate. What type of experience do you have with gcc C/C++ code and garbage collectors. Jeff, being a major gcc developer, is making me nervous here. I want to use a garbage collator to improve development time and avoid memory leeks. However, it won't be worth it to me if I have to spend most of my time tracking down errors due to pointer unsafety. -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-9569-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 07:26:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12042 invoked by alias); 27 Aug 1999 07:26:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12009 invoked from network); 27 Aug 1999 07:25:57 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 27 Aug 1999 07:25:57 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id BAA06361; Fri, 27 Aug 1999 01:17:54 -0600 X-Mailer: exmh version 2.0.2 To: veksler@il.ibm.com cc: egcs@egcs.cygnus.com Subject: Re: Deadly optimization bug (all gcc versions!) Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 16 Aug 1999 16:30:59 +0300. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 01:17:54 -0600 Message-ID: <6358.935738274@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > > The bug shows itself on gcc-2.7.0 gcc-2.7.2.1, egcs-1.0.1, egcs-1.1.2, > gcc-2.95. > On AIX-4.1, Linux-x86 (RH4.2 and RH6.0). > > Just try to compile the following code once with -O and once without. > This may be the reason behind some of the problems with Linux-2.2.xx I doubt this is the reason behind any problems with linux-2.2.xx (especially since it also fails with gcc-2.7.xx) In fact, I'm not aware of any egcs/gcc bugs which cause problems problems with linux-2.2.xx. Anyway, I've added this test to the testsuite. There's been a couple patches submitted to fix it, but I haven't had a chance to evaluate them yet. Thanks, jeff From gcc-return-9570-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 07:31:48 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13581 invoked by alias); 27 Aug 1999 07:31:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13561 invoked from network); 27 Aug 1999 07:31:24 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 27 Aug 1999 07:31:24 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id BAA06380; Fri, 27 Aug 1999 01:22:56 -0600 X-Mailer: exmh version 2.0.2 To: Toon Moene cc: David Edelsohn , veksler@il.ibm.com, egcs@egcs.cygnus.com Subject: Re: Deadly optimization bug (all gcc versions!) Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 16 Aug 1999 21:43:30 +0200. <37B869E2.30CAA4A@moene.indiv.nluug.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 01:22:56 -0600 Message-ID: <6377.935738576@upchuck.cygnus.com> From: Jeffrey A Law In message <37B869E2.30CAA4A@moene.indiv.nluug.nl>you write: > [ General Warning: I have no idea what the C Standard mandates when > shifting an unsigned number by a signed quantity (i.e. the constant > 1) ] As long as the shift count is positive and smaller than the bitsize of the object being shifted, it will do what one would expect :-) The shift count has no bearing on the ultimate type of the expression (the type of the expression is derived solely from the value being shifted). Anyway... > > Maybe combine is trying some alternate instructions, failing, and > > then not properly restoring the instructions? > > Or the other way around (I see a couple of NOTE_INSN_DELETED in the > .combine dump where the .flow dump still has something like: This tends to indicate that combine thought it could simplify the expression into a nop. > [ Flow is run before combine, isn't it - doesn't combine need some > flow graph info to decide whether certain combine's are valid ? ] flow is run before combine and provides the combiner with the dataflow information to drive what combinations it will try. ie, it provides use-def chain pointers. The combiner then tries to combine the definition of a value with the use of the value. jeff From gcc-return-9571-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 07:35:17 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15152 invoked by alias); 27 Aug 1999 07:35:05 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15102 invoked from network); 27 Aug 1999 07:35:00 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 27 Aug 1999 07:35:00 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id BAA06445; Fri, 27 Aug 1999 01:26:11 -0600 X-Mailer: exmh version 2.0.2 To: Franz Sirl cc: Joern Rennecke , dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com Subject: Re: Deadly optimization bug (all gcc versions!) Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 17 Aug 1999 01:25:00 +0200. <99081701395000.00901@ns1102.munich.netsurf.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 01:26:11 -0600 Message-ID: <6442.935738771@upchuck.cygnus.com> From: Jeffrey A Law In message <99081701395000.00901@ns1102.munich.netsurf.de>you write: > >try_combine assumes that i2 feeds i3, and i1 feeds i2 and/or i3. > >This is clearly not the case here, the the call is in error. > >Look for the cause, probably some bogus LOG_LINKS. > > Argh, sorry. I did not backscroll far enough, the correct i3,i2,i1 at the > beginning are: :-) One of fun things about try_combine is it modifies the RTL hunks you see. So you have to peek at them as soon as you get into try_combine before they get modified. [ ... ] > So the feed rules are fulfilled. In the meantime I believe I narrowed it > down a bit to this code around line 1740: > > /* If we already got a failure, don't try to do more. Otherwise, > try to substitute in I1 if we have it. */ > > if (i1 && GET_CODE (newpat) != CLOBBER) > { > /* Before we can do this substitution, we must redo the test done > above (see detailed comments there) that ensures that I1DEST > isn't mentioned in any SETs in NEWPAT that are field assignments. > */ > > if (! combinable_i3pat (NULL_RTX, &newpat, i1dest, NULL_RTX, > 0, NULL_PTR)) > { > undo_all (); > return 0; > } > > n_occurrences = 0; > subst_low_cuid = INSN_CUID (i1); > newpat = subst (newpat, i1dest, i1src, 0, 0); > undobuf.previous_undos = undobuf.undos; > } > > > Before the call to subst newpat/i1dest/i1src look like: [ ... ] This sounds like we're performing a substitution, then simplification (subst calls a ton of simplification routines). I'd bet we botch something in the simplification process. jeff From gcc-return-9572-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 07:40:15 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16916 invoked by alias); 27 Aug 1999 07:40:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16857 invoked from network); 27 Aug 1999 07:39:55 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 27 Aug 1999 07:39:55 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id BAA06464; Fri, 27 Aug 1999 01:31:22 -0600 X-Mailer: exmh version 2.0.2 To: veksler@il.ibm.com cc: Franz Sirl , Joern Rennecke , dje@watson.ibm.com, egcs@egcs.cygnus.com Subject: Re: Deadly optimization bug (all gcc versions!) Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 22 Aug 1999 08:57:33 +0300. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 01:31:22 -0600 Message-ID: <6461.935739082@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > Am Mit, 18 Aug 1999 schrieb Franz Sirl: > Is there anyone trying to fix this? If not, I suppose this bug & analysis > should enter People are working on it. Generally we do not put simple bugs into the todo list or anything like that -- unless they are horribly complex and require a lot of infrastructure work to fix. jeff From gcc-return-9573-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 07:45:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19683 invoked by alias); 27 Aug 1999 07:45:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19561 invoked from network); 27 Aug 1999 07:45:08 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 27 Aug 1999 07:45:08 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id BAA06537; Fri, 27 Aug 1999 01:36:55 -0600 X-Mailer: exmh version 2.0.2 To: Kevin Atkinson cc: Per Bothner , gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter Reply-To: law@cygnus.com In-reply-to: Your message of Fri, 27 Aug 1999 03:24:16 EDT. <37C63D20.3F912988@home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 01:36:54 -0600 Message-ID: <6534.935739414@upchuck.cygnus.com> From: Jeffrey A Law In message <37C63D20.3F912988@home.com>you write: > Per Bothner wrote: > > > Again, it seems that "pointer unsafety" is a mostly hypothetical problem, > > *assuming* you don't replace all your mallocs by gcmalloc, or otherwise > > use gcmalloc when malloc is more appropriate. > > What type of experience do you have with gcc C/C++ code and garbage > collectors. Jeff, being a major gcc developer, is making me nervous > here. Per's got more than a clue :-) We just approach problems from different directions. He's got a lot more experience with garbage collection and front-ends while my experience is mostly in the backend and optimizers. > I want to use a garbage collator to improve development time and avoid > memory leeks. However, it won't be worth it to me if I have to spend > most of my time tracking down errors due to pointer unsafety. Even though I know the potential for losing exists, I've never seen it happen in practice. That could be because I do not spend a lot of time working with code that does garbage collection, or because gcc is not as aggressive with these kinds of opts as it should be. Also keep in mind the problem only occurs if you have these weird opts and you fire up the collector in the window where the compiler has scrambled your code beyond imagination. jeff From gcc-return-9574-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 08:26:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29628 invoked by alias); 27 Aug 1999 08:26:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29547 invoked from network); 27 Aug 1999 08:26:25 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 27 Aug 1999 08:26:25 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id CAA06716; Fri, 27 Aug 1999 02:17:49 -0600 X-Mailer: exmh version 2.0.2 To: Bernd Schmidt cc: Franz Sirl , Joern Rennecke , dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com, kenner@vlsi1.ultra.nyu.edu Subject: Re: Deadly optimization bug (all gcc versions!) Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 24 Aug 1999 15:14:57 BST. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 02:17:49 -0600 Message-ID: <6713.935741869@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > insn 11 : set (reg 24) [some value] > insn 13 [i1]: set (reg 25) [some value] > insn 16 : set (reg 24) (plus (reg 24) (const_int 1)) > insn 18 [i2]: set (reg 27) (lshiftrt (reg 24) (const_int 1)) > insn 20 [i3]: set (reg 26) (plus (reg 27) (reg 25)) > > We already substituted i2 into i3 and got a (valid) newpat that contains > reg 24. Then, we try to substitute i1 into the newpat. > subst_low_cuid gets set to INSN_CUID (i1). reg_last_set[24] is insn 16 at > this point. The problem is that get_last_value returns the SET_SRC of > insn 11, completely ignoring insn 16. What may not be obvious here is the for loop in question starts at i3, then walks backwards to the previous real insn before i1. It took a few minutes for me to pick up on that important tidbit. > The whole block of code looks very suspicious, though. I'm under the > impression it can't ever find a valid set. I don't see how either. But I'd like to look at it again when my eyes are less tired. > * combine.c (get_last_value): Don't look for earlier sets if the last > known set is somewhere in between the insns being combined. Please go ahead and install this change. Thanks, jeff From gcc-return-9575-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 09:01:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3453 invoked by alias); 27 Aug 1999 09:01:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3399 invoked from network); 27 Aug 1999 09:00:49 -0000 Received: from pop3.dassault-aviation.fr (62.161.178.177) by egcs.cygnus.com with SMTP; 27 Aug 1999 09:00:49 -0000 Received: from rnis.dassault-aviation.fr ([193.106.72.203]) by pop3.dassault-aviation.fr (Netscape Messaging Server 3.5) with SMTP id AAA58B4; Fri, 27 Aug 1999 11:00:14 +0200 Received: from dassault-aviation.fr by rnis.dassault-aviation.fr. (SMI-8.6/SMI-SVR4) id KAA05557; Fri, 27 Aug 1999 10:57:56 +0200 Message-ID: <37C65503.8C244F1D@dassault-aviation.fr> Date: Fri, 27 Aug 1999 11:06:11 +0200 From: Thierry Bravier Organization: Dassault Aviation X-Mailer: Mozilla 4.08 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: C++ Garbage Collecter Content-Type: multipart/mixed; boundary="------------8D053250736C5FD938E260DA" This is a multi-part message in MIME format. --------------8D053250736C5FD938E260DA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit gcc Digest 25 Aug 1999 17:11:10 -0000 Issue 352 C++ Garbage Collecter 9471 by: Kevin Atkinson 9472 by: Jeffrey A Law 9474 by: Per Bothner --------------8D053250736C5FD938E260DA Content-Type: message/rfc822; name="gcc.9471" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gcc.9471" Message-ID: <37C36B3B.DDAD6A0E@home.com> Date: Wed, 25 Aug 1999 00:04:11 -0400 From: Kevin Atkinson MIME-Version: 1.0 To: law@cygnus.com CC: Brian Beuning , gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeffrey A Law wrote: > > In message <37C34F21.95D56129@home.com>you write: > > Brian Beuning wrote: > > > > > We used the Boehm collector on my last project and it worked very > > > well for us. > > > > Does gcc optimizations cause any problems with the garbage collector? > They certainly have the potential to cause problems with garbage collectors. Then I guess the question is: Does anyone have any plans on making gcc garbage collector safe? -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ --------------8D053250736C5FD938E260DA Content-Type: message/rfc822; name="gcc.9472" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gcc.9472" To: Kevin Atkinson cc: Brian Beuning , gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter Reply-To: law@cygnus.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Aug 1999 22:09:11 -0600 Message-ID: <2893.935554151@upchuck.cygnus.com> From: Jeffrey A Law In message <37C36B3B.DDAD6A0E@home.com>you write: > Then I guess the question is: Does anyone have any plans on making gcc > garbage collector safe? Yes, but no specifics yet. This is driven by the ultimate desire to be able to hook in a garbage collector into gcc itself. jeff --------------8D053250736C5FD938E260DA Content-Type: message/rfc822; name="gcc.9474" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gcc.9474" To: gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter From: Per Bothner Date: 24 Aug 1999 22:09:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Jeffrey A Law writes: > > There are a couple of coding techniques that can cause trouble. > > 1. Only storing (only) a pointer to an object that is outside the object, > > > > for example > > char * alloc() { > > char * x = (char *) malloc( 100 ); > > return x-10; > > } > > then the calling code knows to add 10 before using it. This is highly > > perverse code and not likely to be found in practice, but it would break > > the Boehm GC. > Actually, compilers do this internally sometimes as it allows them to > generate more efficient loop code. I don't think these statements are very relevant. Yes, the compiler sometimes does such re-writing, but that is not a problem for a conservative collectors as long as there is still a pointer somewhere that points to the actual base of the object. And either you have a newly allocated object that will be passed to someone, or it was an existing object that was passed from somewhere (as an argument). In either case, you would have a pointer to the base object somewhere. There is one problem I can think of: Allocating a temporary object is only used *local* to a function: char *x = (char*) gcmalloc(100); ... do stuff with x ... /* at this point x is dead */ Here you are the risk that x might be prematurely collected. The work-around is easy: Don't do that. Instead, use non gc-managed memory for objects only used internally in a single function: class malloced { void *p; malloced(void *ptr) { p = ptr; } ~malloced() { free(p); } } char *x = (char*) malloc(100); malloced(x); ... do stuff with x ... /* malloced's finalizer will free x. */ There is at least one example of this "bad" use of gc'd memory in libgjc, in the calls to _Jv_AllocBytes in java/lang/natSystem.cc. I argued against using gc'd memory for such buffers, mainly as a matter of style. But I think we here have another reason to avoid it. (In the case at hand in natSystem.cc, I think we are safe, because the buffer is passed as an argument to getpwuid_r, and there is no arithmetic on the pointer.) In practice, you are much more likely to get hosed by other problems (including compiler bugs) than having the optimizer screw up conservative collection. It is a theoretical problem, but my impression is that it is not an issue in practice. -- --Per Bothner bothner@pacbell.net per@bothner.com http://home.pacbell.net/bothner/ --------------8D053250736C5FD938E260DA Content-Type: message/rfc822; name="gcc.9476" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gcc.9476" Message-ID: <37C382F4.39E791CD@home.com> Date: Wed, 25 Aug 1999 01:45:24 -0400 From: Kevin Atkinson MIME-Version: 1.0 To: Per Bothner CC: gcc@gcc.gnu.org Subject: Bad C++ code (was Re: C++ Garbage Collecter) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Per Bothner wrote: have a pointer to the base object somewhere. > > There is one problem I can think of: Allocating a temporary object > is only used *local* to a function: > > char *x = (char*) gcmalloc(100); > ... do stuff with x ... > /* at this point x is dead */ > > Here you are the risk that x might be prematurely collected. The > work-around is easy: Don't do that. Instead, use non gc-managed > memory for objects only used internally in a single function: > > class malloced { > void *p; > malloced(void *ptr) { p = ptr; } > ~malloced() { free(p); } > } > > char *x = (char*) malloc(100); > malloced(x); except that malloced(x) will be deleted here (before the next line) What you wanted to say was malloced x0 = x; > ... do stuff with x ... > /* malloced's finalizer will free x. */ -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ --------------8D053250736C5FD938E260DA-- From gcc-return-9576-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 11:05:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29366 invoked by alias); 27 Aug 1999 11:05:06 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29307 invoked from network); 27 Aug 1999 11:05:00 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 27 Aug 1999 11:05:00 -0000 Received: (qmail 24575 invoked by alias); 27 Aug 1999 11:04:57 -0000 Received: (qmail 24560 invoked from network); 27 Aug 1999 11:04:56 -0000 Received: from biriani.cygnus.co.uk (bernds@194.130.39.16) by dns.cygnus.co.uk with SMTP; 27 Aug 1999 11:04:56 -0000 Received: from localhost by biriani.cygnus.co.uk (UUNET PIPEX simple 1.30) id MAA15674; Fri, 27 Aug 1999 12:04:50 +0100 Date: Fri, 27 Aug 1999 12:04:50 +0100 (BST) From: Bernd Schmidt To: Jeffrey A Law cc: Franz Sirl , Joern Rennecke , dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com, kenner@vlsi1.ultra.nyu.edu Subject: Re: Deadly optimization bug (all gcc versions!) In-Reply-To: <6713.935741869@upchuck.cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > > * combine.c (get_last_value): Don't look for earlier sets if the last > > known set is somewhere in between the insns being combined. > Please go ahead and install this change. Done. Do we want this for 2.95.2? Bernd From gcc-return-9577-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 11:38:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 913 invoked by alias); 27 Aug 1999 11:37:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 773 invoked from network); 27 Aug 1999 11:37:28 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 27 Aug 1999 11:37:28 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id NAA25288; Fri, 27 Aug 1999 13:37:00 +0200 (MET DST) Date: Fri, 27 Aug 1999 13:36:59 +0200 (MET DST) From: Gerald Pfeifer To: Jonathan Roy cc: gcc@gcc.gnu.org Subject: Re: Configure/make problem In-Reply-To: <199908261116410910.003E1CCE@smtp-server.tampabay.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 26 Aug 1999, Jonathan Roy wrote: > I'm trying to compile it outside of the source tree just like the docs > recommend. I've always just compiled it in-place in the source tree in the > past with no problems. Thought I should point out this isn't working, > although it's very possible I'm doing something wrong... Solaris 2.7 > machine. It seems you are using Sun make, right? Sun make is not fully POSIX compliant (at least that's what I have been told) and thus won't work for objdir != srcdir. The installation documentation always specified that you should use GNU make, but I have now installed the following patch to make this even more clearn. Provide more details about broken versions of make. Minor markup fixes. http://egcs.cygnus.com/install/build.html Gerald Index: build.html =================================================================== RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/install/build.html,v retrieving revision 1.20 diff -r1.20 build.html 4a5 > 11,12c12,17 <

    We highly recommend that GCC be built using GNU make; other < versions may work, then again they might not. To be safe build with GNU make. --- >

    We highly recommend that GCC be built using GNU make; > other versions may work, then again they might not.

    > >

    (For example, many broken versions of make will fail if you use the > recommended setup where objdir is different from srcdir.) > 21c26 < gperf.

    --- > gperf. 24c29 < binutils if they have been properly unpacked into the GCC source tree.

    --- > binutils if they have been properly unpacked into the GCC source tree. 26c31 <

  • Perform a 3-stage bootstrap of the compiler.

    --- >

  • Perform a 3-stage bootstrap of the compiler. 28c33 <
  • Perform a comparison test of the stage2 and stage3 compilers.

    --- >

  • Perform a comparison test of the stage2 and stage3 compilers. 53a59 > 96c102 < Last modified on July 16, 1999. --- > Last modified on August 27, 1999. From gcc-return-9578-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 11:47:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3422 invoked by alias); 27 Aug 1999 11:46:39 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3350 invoked from network); 27 Aug 1999 11:46:32 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 27 Aug 1999 11:46:32 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id NAA27196; Fri, 27 Aug 1999 13:44:37 +0200 Message-ID: <37C67A25.4DF8F494@moene.indiv.nluug.nl> Date: Fri, 27 Aug 1999 13:44:37 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: Mumit Khan CC: craig@jcb-sc.com, gcc@gcc.gnu.org Subject: Re: case of G77 symbol tables References: <199908261954.OAA18146@mercury.xraylith.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mumit Khan wrote: > Please use http://www.fortran.com/fortran/ to refer to the Fortran Market > instead of kumo.swcp.com. > > For FAQ's and other resources, see: > > http://www.fortran.com/fortran/info.html > > It has pointers to the FAQ and whole bunch of other stuff. However, I > don't really know how useful these links are in reality. We already point to it via the `Readings' section of the GCC Home Page. [ Walt Brainerd wrote me 2 months ago that the second `fortran' "won't be necessary soon", but it still seems needed ] I think these links are really useful (one thing to note is that there are *two* Fortran FAQs: One that is maintained by Keith Bierman, which is pertinent to comp.lang.fortran and one that's more about Fortran 90). BTW, the _original_ question leading up to this discussion on FAQs was the interoperability between Fortran and C, a topic on which the g77 documentation also has a lot to say. -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-9579-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 14:16:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14364 invoked by alias); 27 Aug 1999 14:16:39 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14342 invoked from network); 27 Aug 1999 14:16:29 -0000 Received: from garfield.dis.com (199.4.97.30) by egcs.cygnus.com with SMTP; 27 Aug 1999 14:16:29 -0000 Received: from garfield (199.4.97.30) by garfield.dis.com (EMWAC SMTPRS 0.81) with SMTP id ; Fri, 27 Aug 1999 07:16:24 -0700 Message-Id: <4.1.19990827070612.00c4bc00@garfield.dis.com> X-Sender: mark@garfield.dis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 27 Aug 1999 07:16:23 -0700 To: law@cygnus.com From: Mark Klein Subject: Re: HARD_REGNO_MODE_OK on PA-RISC (revisited) Cc: gcc@gcc.gnu.org In-Reply-To: <5975.935734480@upchuck.cygnus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 12:14 AM 8/27/99 -0600, Jeffrey A Law wrote: >Note that the code in question has changed quite a bit recently in preparation >for PA64 support. Where do you stand with your various merges, especially the MPE port? I'd like to get (at least the core port) into a release so I can relax about trying to track all the changes coming from Jerry and you. I converted FUNCTION_ARG from a macro to a procedure call to try to simplify life (you're right ... it did take a few readings to understand it, and I'm not sure I understand all of it :-)), and I'm sure that is also an area that is being worked on for PA 2.0. I'd be happy to resubmit my patches if that'll make life easier for you. It may take a few days to break them down into separate core port, long double changes, and millicode performance changes due to current scheduling issues. Regards, M. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available From gcc-return-9580-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 14:46:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18481 invoked by alias); 27 Aug 1999 14:46:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18412 invoked from network); 27 Aug 1999 14:46:26 -0000 Received: from tas15-atm.tampabay.rr.com (root@24.92.0.65) by egcs.cygnus.com with SMTP; 27 Aug 1999 14:46:26 -0000 Received: from dunamis.tampabay.rr.com (dt0f3n7b.tampabay.rr.com [24.92.179.123]) by tas15-atm.tampabay.rr.com (8.9.3/8.9.3) with ESMTP id KAA05565; Fri, 27 Aug 1999 10:38:19 -0400 (EDT) Message-ID: <199908271045550150.000CCCE0@smtp-server.tampabay.rr.com> In-Reply-To: References: X-Mailer: Calypso Version 3.00.00.14 (2) Date: Fri, 27 Aug 1999 10:45:55 -0400 Reply-To: roy@idle.com From: "Jonathan Roy" To: "Gerald Pfeifer" Cc: gcc@gcc.gnu.org Subject: Re: Configure/make problem Content-Type: text/plain; charset="us-ascii" Ah ok, thank you. :) Turns out gnumake wasn't properly installed, it should have been. I discovered it was missing when another package failed to compile, and it printed a warning about needing gnumake. Thanks again, -Jonathan *********** REPLY SEPARATOR *********** On 8/27/99 at 1:36 PM Gerald Pfeifer wrote: >On Thu, 26 Aug 1999, Jonathan Roy wrote: >> I'm trying to compile it outside of the source tree just like the docs >> recommend. I've always just compiled it in-place in the source tree in the >> past with no problems. Thought I should point out this isn't working, >> although it's very possible I'm doing something wrong... Solaris 2.7 >> machine. > >It seems you are using Sun make, right? Sun make is not fully POSIX >compliant (at least that's what I have been told) and thus won't work >for objdir != srcdir. > >The installation documentation always specified that you should use GNU >make, but I have now installed the following patch to make this even more >clearn. > > Provide more details about broken versions of make. > Minor markup fixes. > >http://egcs.cygnus.com/install/build.html > >Gerald > >Index: build.html >=================================================================== >RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/install/build.html,v >retrieving revision 1.20 >diff -r1.20 build.html >4a5 >> >11,12c12,17 ><

    We highly recommend that GCC be built using GNU make; other >< versions may work, then again they might not. To be safe build with GNU make. >--- >>

    We highly recommend that GCC be built using GNU make; >> other versions may work, then again they might not.

    >> >>

    (For example, many broken versions of make will fail if you use the >> recommended setup where objdir is different from srcdir.) >> >21c26 >< gperf.

    >--- >> gperf. >24c29 >< binutils if they have been properly unpacked into the GCC source tree.

    >--- >> binutils if they have been properly unpacked into the GCC source tree. >26c31 ><

  • Perform a 3-stage bootstrap of the compiler.

    >--- >>

  • Perform a 3-stage bootstrap of the compiler. >28c33 ><
  • Perform a comparison test of the stage2 and stage3 compilers.

    >--- >>

  • Perform a comparison test of the stage2 and stage3 compilers. >53a59 >> >96c102 >< Last modified on July 16, 1999. >--- >> Last modified on August 27, 1999. --- Jonathan Roy - roy@idle.com - Idle Communications, Inc. From gcc-return-9581-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 15:28:50 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30597 invoked by alias); 27 Aug 1999 15:28:42 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30578 invoked from network); 27 Aug 1999 15:28:36 -0000 Received: from vss26.vss.fsi.com (HELO esds.vss.fsi.com) (199.217.137.156) by egcs.cygnus.com with SMTP; 27 Aug 1999 15:28:36 -0000 Received: from eos.vss.fsi.com (eos.vss.fsi.com [198.51.27.130]) by esds.vss.fsi.com (8.9.1a/8.9.1) with ESMTP id KAA11921 for ; Fri, 27 Aug 1999 10:27:17 -0500 (CDT) Received: from localhost (ford@localhost) by eos.vss.fsi.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA06021 for ; Fri, 27 Aug 1999 10:25:44 -0500 (CDT) X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Fri, 27 Aug 1999 10:25:44 -0500 (CDT) From: Brian Ford X-Sender: ford@eos To: gcc@gcc.gnu.org Subject: Re: Configure/make problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 27 Aug 1999, Gerald Pfeifer wrote: > 24c29 > < binutils if they have been properly unpacked into the GCC source tree.

    > --- > > binutils if they have been properly unpacked into the GCC source tree. > This just triggered a suggestion. It seems that the "what does properly unpacked mean" question often appears. Maybe a sentence or two in the FAQ describing what this means would be appropriate? I'm not sure if I'm qualified to make that clarification, but I could try if you like. -- Brian Ford Software Engineer Vital Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 From gcc-return-9582-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 16:00:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2754 invoked by alias); 27 Aug 1999 16:00:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2734 invoked by uid 22784); 27 Aug 1999 16:00:06 -0000 From: Tom Tromey Newsgroups: cygnus.egcs Subject: Re: C++ Garbage Collecter Date: 27 Aug 1999 09:54:13 -0600 Organization: Cygnus Solutions Lines: 35 Message-ID: <87hfllte1m.fsf@cygnus.com> References: <8574.935654387@upchuck.cygnus.com> Reply-To: tromey@cygnus.com NNTP-Posting-Host: rtl.cygnus.com X-Zippy: I always liked FLAG DAY!! X-Attribution: Tom X-Newsreader: Gnus v5.5/Emacs 20.2 To: egcs@egcs.cygnus.com DJ-Gateway: from newsgroup cygnus.egcs >>>>> "Per" == Per Bothner writes: Per> You misunderstand. I am in favor of using (say) "gcmalloc" to Per> allocate gc'd objects. I am *against* having malloc become as a Per> wrapper for gcmalloc. My understanding is that this is precisely how people use the Boehm GC -- they plug it in to their programs as a malloc replacement. Per> Again, it seems that "pointer unsafety" is a mostly hypothetical Per> problem, *assuming* you don't replace all your mallocs by Per> gcmalloc, or otherwise use gcmalloc when malloc is more Per> appropriate. Your example in an earlier message proposed the idea that this problem can only happen when allocating a temporary with a known lifetime. I disagree. I think it can happen any time the last reference to an object is on the stack. This can happen in various situations which we can't predict (though I admit it is hard to think of plausible scenarios for this -- still, it could happen. It might even come about as the result of other code transformations the compiler makes). A more real problem comes with Java arrays. It seems to me that any Java code which uses a temporary array is at risk. I don't think we can tell Java programmers "don't do that". And we can't give them access to non-GC'd memory, either. Finally, I'm curious to know how aggressive gcc can be with these sorts of optimizations. I can imagine that in some bizarre situation it is useful to transform the last pointer to an object, and then later to transform it back in order to pass it as the `this' parameter to a method call. This would make the problem more likely to be seen in practice. Tom From gcc-return-9583-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 16:04:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4360 invoked by alias); 27 Aug 1999 16:03: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4267 invoked from network); 27 Aug 1999 16:03:37 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 27 Aug 1999 16:03:37 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id SAA29218; Fri, 27 Aug 1999 18:03:08 +0200 (MET DST) Date: Fri, 27 Aug 1999 18:03:07 +0200 (MET DST) From: Gerald Pfeifer To: Brian Ford cc: gcc@gcc.gnu.org Subject: Re: Configure/make problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 27 Aug 1999, Brian Ford wrote: > This just triggered a suggestion. It seems that the "what does > properly unpacked mean" question often appears. Maybe a sentence or > two in the FAQ describing what this means would be appropriate? I'm > not sure if I'm qualified to make that clarification, but I could try > if you like. As a matter of fact, asking whether you could give it a try was on my TODO list. No kidding! :-) Just one suggestion: Instead of *answering* FAQs, I would like to *avoid* FAQs, so I believe we want to improve install/build.html itself instead of adding a new FAQ entry. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9584-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 16:16:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8298 invoked by alias); 27 Aug 1999 16:16:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8277 invoked from network); 27 Aug 1999 16:16:36 -0000 Received: from nenuphar.saclay.cea.fr (132.166.192.7) by egcs.cygnus.com with SMTP; 27 Aug 1999 16:16:36 -0000 Received: from muguet.saclay.cea.fr (muguet.saclay.cea.fr [132.166.192.6]) by nenuphar.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.0.D20) with ESMTP id SAA09181 for ; Fri, 27 Aug 1999 18:16:34 +0200 (MET DST) Received: from pendragon-int.shfj.cea.fr (pendragon.shfj.cea.fr [132.166.81.1]) by muguet.saclay.cea.fr (8.9.1a/8.9.1/CEAnet-relay-5.1.D20) with SMTP id SAA12732 for ; Fri, 27 Aug 1999 18:16:30 +0200 (MET DST) Received: by pendragon-int.shfj.cea.fr; id SAA01459; Fri, 27 Aug 1999 18:10:18 +0200 Received: from uriens.shfj.cea.fr(193.48.23.6) by pendragon-int.shfj.cea.fr via smap (3.2) id xma001457; Fri, 27 Aug 99 18:10:09 +0200 Received: from orcanie.shfj.cea.fr by shfj.cea.fr (8.6.10/PROTO-CEANET-3.0) with ESMTP id SAA26561 for ; Fri, 27 Aug 1999 18:15:36 +0200 Received: from orcanie (orcanie [193.48.23.116]) by orcanie.shfj.cea.fr (8.9.1b+Sun/8.9.1) with SMTP id SAA08162 for ; Fri, 27 Aug 1999 18:16:37 +0200 (MET DST) Message-Id: <199908271616.SAA08162@orcanie.shfj.cea.fr> Date: Fri, 27 Aug 1999 18:16:37 +0200 (MET DST) From: Dimitri PAPADOPOULOS-ORFANOS Reply-To: Dimitri PAPADOPOULOS-ORFANOS Subject: Re: egcs/Solaris status To: egcs@egcs.cygnus.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xSSqUeOBmFQ8j+3XGsnhpw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc I wrote: > > Alexandre Oliva wrote: > > > On Aug 21, 1999, Dimitri Papadopoulos wrote: > > > > > 3) I get segfault/aritmetic exception in Qt (http://www.troll.no/),even > > > without -O. The problem is not with Qt: > > > - The very same source compiled with egcs-1.1.2 or Sun CC does not > > > crash. > > > > Did you try to compile with -fno-strict-aliasing? -fstring-aliasing, > > now enabled by default, has caused some problems to packages that use > > certain kinds of casts of pointers with undefined results. > > I tried to compile with -fno-strict-aliasing and using GNU as/ld > this morning. I still get the same segfault [...] Indeed, after a few more tests: - This is not an -fstrict-aliasing/-fno-strict-aliasing issue. These switches make no real difference. In fact, the program fails less often when using -fstrict-aliasing than when using -fno-strict-aliasing. - This is not really a Sun as/ld issue. I have built Qt with Sun as/ld and then with GNU as/ld. The program fails less often when using GNU as/ld, but fails nevertheless. I believe this is a Solaris bug that triggers a crash more or less often depending on the use of GNU as/ld vs. Sun as/ld or on the use of -fno-strict-aliasing. These options have a small impact on the binary files output produced by the GCC. Depending on which option was chosen, the program crashes more or less frequently: - GCC 2.95.1 with GNU as/ld (/bin in the PATH + links in /lib/gcc-lib/sparc-sun-solaris2.7/2.95.1 + /usr/ccs/bin out of the PATH + -fstrict-aliasing): The program crashes randomly (1 failure out of ~100 runs). $ ./examples/application/application $ ./examples/application/application $ ./examples/application/application $ ./examples/application/application *** never allocated! Floating exception $ ./examples/application/application $ ./examples/application/application $ ./examples/application/application - GCC 2.95.1 used with Sun as/ld (/usr/ccs/bin in the PATH + no links in /lib/gcc-lib/sparc-sun-solaris2.7/2.95.1 + -fstrict-aliasing): The program crashes every time, except the first time it is run after a login or after other heavy use of the machine. The program crashes because in some method 'this' is an invalid, never allocated pointer (I keep track of allocated pointers), and because a private variable 'vlen' of this inexistant 'this' has a value of 0 and is used this way: ... = ... % vlen; If I build with EGCS 1.1.2, the program never crashes. When I build with GCC 2.95.1, the program crashes randomly, but never the first time the shared library is loaded. In addition, building with GCC 2.95.1 on Linux does never result in a crash. Any ideas? A problem in the SPARC assembler output by GCC? A problem in the Solaris runtime linker? How to debug this? Is this a known problem with Solaris 7? Thank you in advance, -- Dimitri Papadopoulos From gcc-return-9585-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 16:54:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12662 invoked by alias); 27 Aug 1999 16:54:07 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12631 invoked from network); 27 Aug 1999 16:54:02 -0000 Received: from vss26.vss.fsi.com (HELO esds.vss.fsi.com) (199.217.137.156) by egcs.cygnus.com with SMTP; 27 Aug 1999 16:54:02 -0000 Received: from eos.vss.fsi.com (eos.vss.fsi.com [198.51.27.130]) by esds.vss.fsi.com (8.9.1a/8.9.1) with ESMTP id LAA13620; Fri, 27 Aug 1999 11:52:41 -0500 (CDT) Received: from localhost (ford@localhost) by eos.vss.fsi.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA06157; Fri, 27 Aug 1999 11:51:09 -0500 (CDT) X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Fri, 27 Aug 1999 11:51:08 -0500 (CDT) From: Brian Ford X-Sender: ford@eos To: Gerald Pfeifer cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: Configure/make problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-838545539-935772668=:5870" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-838545539-935772668=:5870 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 27 Aug 1999, Gerald Pfeifer wrote: > On Fri, 27 Aug 1999, Brian Ford wrote: > > It seems that the "what does properly unpacked mean" question often > > appears. Maybe a sentence or two in the FAQ describing what this > > means would be appropriate? I'm not sure if I'm qualified to make > > that clarification, but I could try if you like. > > As a matter of fact, asking whether you could give it a try was on my > TODO list. No kidding! :-) > Wow! I didn't know anyone really noticed me. Cool. > Just one suggestion: Instead of *answering* FAQs, I would like to *avoid* > FAQs, so I believe we want to improve install/build.html itself instead of > adding a new FAQ entry. > Agreed. I guess this was what I really meant in the first place. Ok, This isn't really good, but I believe it is better than what we had before. I also made the list for the native and cross compilers have the same single spacing and added

    • 's where appropriate. -- Brian Ford Software Engineer Vital Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 ---559023410-838545539-935772668=:5870 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="build.html.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="build.html.diff" SW5kZXg6IGJ1aWxkLmh0bWwNCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJD UyBmaWxlOiAvZWdjcy9jYXJ0b24vY3ZzZmlsZXMvd3d3ZG9jcy9odGRvY3Mv aW5zdGFsbC9idWlsZC5odG1sLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4y MQ0KZGlmZiAtdSAtcjEuMjEgYnVpbGQuaHRtbA0KLS0tIGJ1aWxkLmh0bWwJ MTk5OS8wOC8yNyAxMTozNjo0NwkxLjIxDQorKysgYnVpbGQuaHRtbAkxOTk5 LzA4LzI3IDE2OjUxOjU2DQpAQCAtMjMsMTcgKzIzLDE5IEBADQogDQogPHVs Pg0KICAgPGxpPiBCdWlsZCBob3N0IHRvb2xzIG5lY2Vzc2FyeSB0byBidWls ZCB0aGUgY29tcGlsZXIgc3VjaCBhcyB0ZXhpbmZvLCBiaXNvbiwNCi0gIGdw ZXJmLg0KKyAgZ3BlcmYuPC9saT4NCiANCi0gIDxsaT4gQnVpbGQgdGFyZ2V0 IHRvb2xzIGZvciB1c2UgYnkgdGhlIGNvbXBpbGVyIHN1Y2ggYXMgZ2FzLCBn bGQsIGFuZA0KLSAgYmludXRpbHMgaWYgdGhleSBoYXZlIGJlZW4gcHJvcGVy bHkgdW5wYWNrZWQgaW50byB0aGUgR0NDIHNvdXJjZSB0cmVlLg0KKyAgPGxp PiBCdWlsZCB0YXJnZXQgdG9vbHMgZm9yIHVzZSBieSB0aGUgY29tcGlsZXIg c3VjaCBhcyBiaW51dGlscyAoYmZkLA0KKyAgYmludXRpbHMsIGdhcywgZ3By b2YsIGxkLCBhbmQgb3Bjb2Rlcyk8YnI+DQorICBpZiB0aGV5IGhhdmUgYmVl biBpbmRpdmlkdWFsbHkgbGlua2VkIG9yIG1vdmVkIGludG8gdGhlIHRvcCBs ZXZlbCBHQ0Mgc291cmNlDQorICB0cmVlIGJlZm9yZSBjb25maWd1cmluZy48 L2xpPg0KIA0KLSAgPGxpPiBQZXJmb3JtIGEgMy1zdGFnZSBib290c3RyYXAg b2YgdGhlIGNvbXBpbGVyLg0KKyAgPGxpPiBQZXJmb3JtIGEgMy1zdGFnZSBi b290c3RyYXAgb2YgdGhlIGNvbXBpbGVyLjwvbGk+DQogDQotICA8bGk+IFBl cmZvcm0gYSBjb21wYXJpc29uIHRlc3Qgb2YgdGhlIHN0YWdlMiBhbmQgc3Rh Z2UzIGNvbXBpbGVycy4NCisgIDxsaT4gUGVyZm9ybSBhIGNvbXBhcmlzb24g dGVzdCBvZiB0aGUgc3RhZ2UyIGFuZCBzdGFnZTMgY29tcGlsZXJzLjwvbGk+ DQogDQogICA8bGk+IEJ1aWxkIHJ1bnRpbWUgbGlicmFyaWVzIHVzaW5nIHRo ZSBzdGFnZTMgY29tcGlsZXIgZnJvbSB0aGUgcHJldmlvdXMNCi0gIHN0ZXAu DQorICBzdGVwLjwvbGk+DQogPC91bD4NCiANCiA8cD5JZiB5b3UgYXJlIHNo b3J0IG9uIGRpc2sgc3BhY2UgeW91IG1pZ2h0IGNvbnNpZGVyIGA8Y29kZT5t YWtlIA0KQEAgLTc2LDE1ICs3OCwxNyBAQA0KIGZvbGxvd2luZyBzdGVwczoN CiA8dWw+DQogICA8bGk+IEJ1aWxkIGhvc3QgdG9vbHMgbmVjZXNzYXJ5IHRv IGJ1aWxkIHRoZSBjb21waWxlciBzdWNoIGFzIHRleGluZm8sIGJpc29uLA0K LSAgZ3BlcmYuPHA+DQorICBncGVyZi48L2xpPg0KIA0KLSAgPGxpPiBCdWls ZCB0YXJnZXQgdG9vbHMgZm9yIHVzZSBieSB0aGUgY29tcGlsZXIgc3VjaCBh cyBnYXMsIGdsZCwgYW5kDQotICBiaW51dGlscyBpZiB0aGV5IGhhdmUgYmVl biBwcm9wZXJseSB1bnBhY2tlZCBpbnRvIHRoZSBHQ0Mgc291cmNlIHRyZWUu PHA+DQorICA8bGk+IEJ1aWxkIHRhcmdldCB0b29scyBmb3IgdXNlIGJ5IHRo ZSBjb21waWxlciBzdWNoIGFzIGJpbnV0aWxzIChiZmQsDQorICBiaW51dGls cywgZ2FzLCBncHJvZiwgbGQsIGFuZCBvcGNvZGVzKTxicj4NCisgIGlmIHRo ZXkgaGF2ZSBiZWVuIGluZGl2aWR1YWxseSBsaW5rZWQgb3IgbW92ZWQgaW50 byB0aGUgdG9wIGxldmVsIEdDQyBzb3VyY2UNCisgIHRyZWUgYmVmb3JlIGNv bmZpZ3VyaW5nLjwvbGk+DQogDQotICA8bGk+IEJ1aWxkIHRoZSBjb21waWxl ciAoc2luZ2xlIHN0YWdlIG9ubHkpLjxwPg0KKyAgPGxpPiBCdWlsZCB0aGUg Y29tcGlsZXIgKHNpbmdsZSBzdGFnZSBvbmx5KS48L2xpPg0KIA0KICAgPGxp PiBCdWlsZCBydW50aW1lIGxpYnJhcmllcyB1c2luZyB0aGUgY29tcGlsZXIg ZnJvbSB0aGUgcHJldmlvdXMNCi0gIHN0ZXAuDQorICBzdGVwLjwvbGk+DQog PC91bD4NCiANCiA8cD5Ob3RlIHRoYXQgaWYgYW4gZXJyb3Igb2NjdXJzIGlu IGFueSBzdGVwIHRoZSBtYWtlIHByb2Nlc3Mgd2lsbCBleGl0Lg0K ---559023410-838545539-935772668=:5870-- From gcc-return-9586-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 17:29:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19174 invoked by alias); 27 Aug 1999 17:29:24 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19158 invoked from network); 27 Aug 1999 17:29:20 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 27 Aug 1999 17:29:20 -0000 Received: (qmail 8790 invoked by alias); 27 Aug 1999 17:29:18 -0000 Received: (qmail 8785 invoked from network); 27 Aug 1999 17:29:17 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 27 Aug 1999 17:29:17 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id SAA32203; Fri, 27 Aug 1999 18:28:31 +0100 From: Joern Rennecke Message-Id: <199908271728.SAA32203@phal.cygnus.co.uk> Subject: Re: C++ Garbage Collecter In-Reply-To: <87hfllte1m.fsf@cygnus.com> from Tom Tromey at "Aug 27, 1999 9:54:13 am" To: tromey@cygnus.com Date: Fri, 27 Aug 1999 18:28:31 +0100 (BST) Cc: gcc@gcc.gnu.org X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Finally, I'm curious to know how aggressive gcc can be with these > sorts of optimizations. I can imagine that in some bizarre situation > it is useful to transform the last pointer to an object, and then > later to transform it back in order to pass it as the `this' parameter > to a method call. This would make the problem more likely to be seen > in practice. Well, regmove also makes such transformations. It's quite successful for the SH port in lowering instruction counts and register pressure. As to how much of the affected registers come from malloc, that's up to experiments. You could make a malloc package that can tell you if any given pointer is from malloc, and then make loop.c and regmove.c insert some instrumentation code to check if any pointer manipulation has been done on a pointer to malloced memory. From gcc-return-9587-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 18:33:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25487 invoked by alias); 27 Aug 1999 18:33:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25466 invoked from network); 27 Aug 1999 18:33:36 -0000 Received: from mail.teklogix.com (HELO tekincisnts-4.teklogix.com) (207.219.2.10) by egcs.cygnus.com with SMTP; 27 Aug 1999 18:33:36 -0000 Received: from DeadDuck (SW3.teklogix.com [10.128.5.186]) by tekincisnts-4.teklogix.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id RP0DK80C; Fri, 27 Aug 1999 14:33:08 -0400 To: gcc@gcc.gnu.org Subject: Build Status (gcc 2.95.1) From: Bill Pringlemeir Date: 27 Aug 1999 14:24:04 -0400 Message-ID: Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.3 I have built the gcc 2.95.1 sources for the armv4l-unknown-linux-gnu. This is being used a compiler on the Netwinder box made by Hardware Computing Canada (formerly manufactured by Corel). It runs a Red Hat version of Linux. I have also built the first part of a cross compiler of sorts. That is arm-vxworks-coff. I still haven't tested this throughly. I built this cross compiler with the above compiler. I am sending this message in regards to the finalinstall.html page that asked that I check that my system was listed. thanks, Bill From gcc-return-9588-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 20:06:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7433 invoked by alias); 27 Aug 1999 20:06:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7303 invoked from network); 27 Aug 1999 20:05:57 -0000 Received: from jubilee.bbn.com (171.78.41.103) by egcs.cygnus.com with SMTP; 27 Aug 1999 20:05:57 -0000 Received: from chapter (chapter.bbn.com [171.78.42.210]) by jubilee.bbn.com (8.9.2/8.9.2) with SMTP id QAA19787 for ; Fri, 27 Aug 1999 16:05:56 -0400 (EDT) From: "Chris Griffin" To: Subject: Tools for GCC 2.95.1 Date: Fri, 27 Aug 1999 16:03:40 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Hi, I'm looking for someone who can tell me what tools (binutils & gdb) I should be able to use with gcc 2.95.1 . We are using RedHat 6, so would I need to build the most recent gdb, or is it going to work to use the gdb which comes on the system? So the specific questions are: Which version of binutils should I use? Which version of gdb should I use? Thanks, Chris From gcc-return-9589-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 21:51:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20704 invoked by alias); 27 Aug 1999 21:51:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20689 invoked from network); 27 Aug 1999 21:51:38 -0000 Received: from cpimssmtpu02.email.msn.com (HELO smtp.email.msn.com) (207.46.181.18) by egcs.cygnus.com with SMTP; 27 Aug 1999 21:51:38 -0000 Received: from f1i4z3 - 63.10.28.75 by email.msn.com with Microsoft SMTPSVC; Fri, 27 Aug 1999 14:51:04 -0700 Message-ID: <000f01bef0ef$21c8a480$4b1c0a3f@f1i4z3> From: "DANNIELSIMON" To: Subject: Precise directions for installation Date: Fri, 27 Aug 1999 17:49:03 -0700 Organization: Microsoft Corporation MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01BEF0B4.73416E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01BEF0B4.73416E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am trying to install GCC on a PII 400 Win 98 machine. I have downloaded the latest version and put in a file named GCC. I have also downloaded bzip2 and decompressed the GCC file. Now I have a 54MB file but can not install or run it. The online = instructions ofer little help, I would appreciate a detailed instruction set to get me going. Please feel free to ask for more info. Thanks, Dan Simon The quicker I get this installed the better. =20 ------=_NextPart_000_000C_01BEF0B4.73416E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi,
     
    I am trying to install GCC on a PII 400 Win 98=20 machine.
     
    I have downloaded the latest version and put in a = file named=20 GCC.
    I have also downloaded bzip2 and decompressed the = GCC=20 file.
     
    Now I have a 54MB file but can not install or run = it. =20 The online instructions ofer little help,
     
    I would appreciate a detailed instruction set to get = me=20 going.
     
    Please feel free to ask for more info.
     
    Thanks,
     
    Dan Simon
     
    The quicker I get this installed the = better.
     
     
    ------=_NextPart_000_000C_01BEF0B4.73416E40-- From gcc-return-9590-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 21:58:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21958 invoked by alias); 27 Aug 1999 21:57:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21937 invoked from network); 27 Aug 1999 21:57:46 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 27 Aug 1999 21:57:46 -0000 Received: from alphard (alphard [128.130.111.37]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id XAA01815; Fri, 27 Aug 1999 23:57:32 +0200 (MET DST) Date: Fri, 27 Aug 1999 23:57:30 +0200 (MET DST) From: Gerald Pfeifer To: DANNIELSIMON cc: gcc@gcc.gnu.org Subject: Re: Precise directions for installation In-Reply-To: <000f01bef0ef$21c8a480$4b1c0a3f@f1i4z3> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 27 Aug 1999, DANNIELSIMON wrote: > I am trying to install GCC on a PII 400 Win 98 machine. > > I have downloaded the latest version and put in a file named GCC. > I have also downloaded bzip2 and decompressed the GCC file. > > Now I have a 54MB file but can not install or run it. The online > instructions ofer little help, I am afraid you have not read these instructions carefully enough. Please have a look at http://gcc.gnu.org/install/specific.html#win+os2 In addition, even our main page has a news entry concerning Windows! http://gcc.gnu.org/ HTH, Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9591-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 22:09:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25012 invoked by alias); 27 Aug 1999 22:09:46 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24962 invoked from network); 27 Aug 1999 22:09:43 -0000 Received: from adsl-216-102-199-253.dsl.snfc21.pacbell.net (HELO magnus.bothner.com) (root@216.102.199.253) by egcs.cygnus.com with SMTP; 27 Aug 1999 22:09:43 -0000 Received: by bothner.com via sendmail from stdin id (Debian Smail3.2.0.102) for egcs@egcs.cygnus.com; Fri, 27 Aug 1999 15:15:49 -0700 (PDT) To: egcs@egcs.cygnus.com Subject: Re: C++ Garbage Collecter References: <8574.935654387@upchuck.cygnus.com> <87hfllte1m.fsf@cygnus.com> From: Per Bothner Date: 27 Aug 1999 15:15:49 -0700 In-Reply-To: Tom Tromey's message of "27 Aug 1999 09:54:13 -0600 " Message-ID: Lines: 66 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta14) (Dionysos) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Tom Tromey writes: > My understanding is that this is precisely how people use the Boehm GC > -- they plug it in to their programs as a malloc replacement. You're right in that is how some people use it. Sometimes, people have a program written in C such that trying to do manual memory management is too complicated. For example, they may have an existing program with bad hard-to-fix leaks. In that case, just wholesale replacing malloc by gcmalloc may be reasonable thing to do: The slight chance of bugs caused by hypothetical gc-unsafe optimizations are well worth the reduced memory-management hassles and bugs in general. Another major use (which I was thinking of) is when you want to implement a run-time environment for a language that use garbage collecion, such as Java or Scheme. A number of language implementors (including the Cygnus Java group) have used the Boehm collector for this. In such an environment the main use of malloc is in existing libraries, the core run-time system, and general "native code". I think in such an environment you're unlike to have complex/confusing lifetimes: Either something has a fairly predicatble lifetime (such as a temporary buffer), in which case it seems better/safer/cleaner to use plain malloc; or you have a malloc'd object whose lifetime matches some object in your higher-level language, in which case you should hang it off the higher-level object, and have the malloc'd object be free'd by the higher-level object's finalizer. > Your example in an earlier message proposed the idea that this problem > can only happen when allocating a temporary with a known lifetime. I > disagree. I think it can happen any time the last reference to an > object is on the stack. This can happen in various situations which > we can't predict (though I admit it is hard to think of plausible > scenarios for this -- still, it could happen. It might even come > about as the result of other code transformations the compiler makes). The only problem is when *every* remaining reference to the object has been transformed. That means the object (or the root of a group of object) has to have been passed as a parameter, and the pointer cannot have been saved anywhere. E.g. something like: Foo(new Xxx()) or a common Java debugging idiom: new Error().printStackTrace(System.err); Yes, this could be unsafe. I do think this is an instance of a temporary with a known lifetime. However, in this case, the temporary is being created in the higher-level language, and there isn't much the run-time system can do to avoid or detect the problem. > A more real problem comes with Java arrays. It seems to me that any > Java code which uses a temporary array is at risk. I don't think we > can tell Java programmers "don't do that". And we can't give them > access to non-GC'd memory, either. Agreed. We do have an advantage over somebody using a converstive collector as a malloc replacement: We can have the Java front-end emit hints to the compiler that the variable is collected. Hence, as long as a derived pointer is "live", the back-end must make sure to keep the base pointer alive in memory or registers. Of course, this is what implementing gc-safety is all about. It is just that if we have the front-end tell the back-end when a pointer is gc'd, then we can do the nasty gc-unsafe optimizations in other cases. (For people using gcmalloc as a malloc replacement, we'd need a flag to tell the compiler to be safe with all heap pointers.) -- --Per Bothner bothner@pacbell.net per@bothner.com http://home.pacbell.net/bothner/ From gcc-return-9592-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 22:11:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26520 invoked by alias); 27 Aug 1999 22:11:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26484 invoked from network); 27 Aug 1999 22:11:52 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 27 Aug 1999 22:11:52 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id PAA09020; Fri, 27 Aug 1999 15:59:47 -0600 X-Mailer: exmh version 2.0.2 To: Mark Klein cc: gcc@gcc.gnu.org Subject: Re: HARD_REGNO_MODE_OK on PA-RISC (revisited) Reply-To: law@cygnus.com In-reply-to: Your message of Fri, 27 Aug 1999 07:16:23 PDT. <4.1.19990827070612.00c4bc00@garfield.dis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 15:59:47 -0600 Message-ID: <9017.935791187@upchuck.cygnus.com> From: Jeffrey A Law In message <4.1.19990827070612.00c4bc00@garfield.dis.com>you write: > Where do you stand with your various merges, especially the MPE port? I'd l My queue is over 200 patches deep. And unfortunately MPE isn't anywhere near the top of the list. Simply a matter of priorities. > track all the changes coming from Jerry and you. I converted FUNCTION_ARG > from a :-) I did something similar already. We're still beating on it internally before we contribute it. jeff From gcc-return-9593-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 22:20:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28189 invoked by alias); 27 Aug 1999 22:20:46 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28174 invoked from network); 27 Aug 1999 22:20:40 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 27 Aug 1999 22:20:40 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id QAA09078; Fri, 27 Aug 1999 16:06:59 -0600 X-Mailer: exmh version 2.0.2 To: Bernd Schmidt cc: Franz Sirl , Joern Rennecke , dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com, kenner@vlsi1.ultra.nyu.edu Subject: Re: Deadly optimization bug (all gcc versions!) Reply-To: law@cygnus.com In-reply-to: Your message of Fri, 27 Aug 1999 12:04:50 BST. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 16:06:59 -0600 Message-ID: <9075.935791619@upchuck.cygnus.com> From: Jeffrey A Law In message you write: > > > > > * combine.c (get_last_value): Don't look for earlier sets if th > e last > > > known set is somewhere in between the insns being combined. > > Please go ahead and install this change. > > Done. Do we want this for 2.95.2? I'll make that decision after I spend some more time looking at the code. jeff From gcc-return-9594-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 22:28:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29351 invoked by alias); 27 Aug 1999 22:28:44 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29334 invoked from network); 27 Aug 1999 22:28:40 -0000 Received: from windlord.stanford.edu (171.64.12.23) by egcs.cygnus.com with SMTP; 27 Aug 1999 22:28:39 -0000 Received: (qmail 14420 invoked by uid 50); 27 Aug 1999 22:28:29 -0000 To: Gerald Pfeifer Cc: gcc@gcc.gnu.org Subject: Re: Lost specific.html FAQ Entry References: From: Russ Allbery In-Reply-To: Gerald Pfeifer's message of "Fri, 27 Aug 1999 19:03:21 +0200 (MET DST)" Date: 27 Aug 1999 15:28:29 -0700 Message-ID: Lines: 22 X-Mailer: Gnus v5.4.66/Emacs 19.34 Gerald Pfeifer writes: > Index: specific.html >>

    all ELF targets (SVR4, Solaris, etc.)

    >> >>

    C++ support is significantly better on ELF targets if you use the GNU >> linker; duplicate copies of inlines, vtables and template instantiations >> will be discarded automatically.

    FYI, GNU ld from binutils 2.9.1 fails to successfully link Perl 5.005_03 on Solaris 2.6. I haven't tried other versions of Solaris. (Perl's hint files try to keep you from using GNU ld on Solaris, saying that it won't work correctly, and they are apparently entirely correct since overriding that results in a non-functional Perl build.) I was going to install gcc 2.95.1 here to use GNU ld on Solaris, given the above note, but that was a sufficiently severe problem to cause me to drop back to the vendor linker. -- Russ Allbery (rra@stanford.edu) From gcc-return-9595-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 22:33:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30274 invoked by alias); 27 Aug 1999 22:33: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30255 invoked from network); 27 Aug 1999 22:33:22 -0000 Received: from windlord.stanford.edu (171.64.12.23) by egcs.cygnus.com with SMTP; 27 Aug 1999 22:33:21 -0000 Received: (qmail 14444 invoked by uid 50); 27 Aug 1999 22:33:14 -0000 To: Dimitri PAPADOPOULOS-ORFANOS Cc: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <199908271616.SAA08162@orcanie.shfj.cea.fr> From: Russ Allbery In-Reply-To: Dimitri PAPADOPOULOS-ORFANOS's message of "Fri, 27 Aug 1999 18:16:37 +0200 (MET DST)" Date: 27 Aug 1999 15:33:14 -0700 Message-ID: Lines: 21 X-Mailer: Gnus v5.4.66/Emacs 19.34 Dimitri PAPADOPOULOS-ORFANOS writes: > I believe this is a Solaris bug that triggers a crash more or less often > depending on the use of GNU as/ld vs. Sun as/ld or on the use of > -fno-strict-aliasing. These options have a small impact on the binary > files output produced by the GCC. Depending on which option was chosen, > the program crashes more or less frequently: This may be an obvious suggestion, since it's listed in install/specific, but I haven't seen it mentioned so far in this thread. You *have* made sure to not install patch 107058-01 or to patchrm it if you had it installed, correct? With that patch installed, make bootstrap fails for me on Solaris 7 with either an older version of gcc or with Solaris cc as the compiler; I get a segfault in the middle of the build or comparison failures between stage2 and stage3. With that patch removed, gcc 2.95.1 bootstraps cleanly and appears to work fine. -- Russ Allbery (rra@stanford.edu) From gcc-return-9596-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 22:39:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31410 invoked by alias); 27 Aug 1999 22:39:30 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31395 invoked from network); 27 Aug 1999 22:39:25 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 27 Aug 1999 22:39:25 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id SAA29414 for ; Fri, 27 Aug 1999 18:39:19 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (root@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id SAA27986 for ; Fri, 27 Aug 1999 18:37:23 -0400 (EDT) Received: (qmail 29688 invoked by uid 500); 27 Aug 1999 22:35:27 -0000 Date: 27 Aug 1999 22:35:27 -0000 Message-ID: <19990827223527.29687.qmail@deer> To: flynn@lure.u-psud.fr CC: gcc@gcc.gnu.org cc: craig@jcb-sc.com In-reply-to: <37C53F6A.C99009BC@lure.u-psud.fr> (message from Gerard Flynn on Thu, 26 Aug 1999 15:21:46 +0200) Subject: Re: Using g77 and gdb together References: <37C2A770.C55551C6@lure.u-psud.fr> <19990824144005.22174.qmail@deer> <37C2E6B1.8AED4A73@lure.u-psud.fr> <19990824211351.24295.qmail@deer> <37C53F6A.C99009BC@lure.u-psud.fr> >line 1550: ffewhereLineNumber linecount_current = ffelex_linecount_current_; > >and > >line 1605: ffelex_linecount_current_ = linecount_current; > >I've tried this and so far everything seems to be working fine. I'm now >able to debug a program with 2 levels of INCLUDE with no problems >whatsoever (at least as far as following the source goes). > >It seems to me that it would really be worth the effort for someone who >knows a lot more about g77 than I to check and see if this modifcation >makes sense and isn't likely to cause other problems because it makes >a night versus day improvement in debugging files with nested INCLUDE's. I've just tried this patch, and it has no effect whatsover on my private test suite. Apparently that's due to a bug in it (my suite, not the patch), in that it doesn't pick up INCLUDE files correctly. So, the good news is that this patch doesn't seem to break anything as far as I can see. The better news is that, indeed, when I compile a simple nested-INCLUDE example and debug it, this patch makes gdb much happier -- no complaints about the line numbers being out-of-range. So I approve this patch, which I include below as a more "proper" one. Want to write a ChangeLog entry? tq vm, (burley) P.S. Sorry it took me a bit of time to get to this. I wanted to bring my test suite and gcc-directory build tree up to date before working on it, and found a problem or two while doing that. *** g77-e/gcc/f/lex.c.~1~ Sat Mar 27 05:23:57 1999 --- g77-e/gcc/f/lex.c Fri Aug 27 10:43:55 1999 *************** ffelex_include_ () *** 1548,1552 **** ffewhereColumnNumber final_nontab_column = ffelex_final_nontab_column_; ffewhereFile current_wf = ffelex_current_wf_; - ffewhereLineNumber linecount_current = ffelex_linecount_current_; ffewhereLineNumber linecount_offset = ffewhere_line_filelinenum (current_wl); --- 1548,1551 ---- *************** ffelex_include_ () *** 1603,1607 **** lineno = old_lineno; #endif - ffelex_linecount_current_ = linecount_current; ffelex_current_wf_ = current_wf; ffelex_final_nontab_column_ = final_nontab_column; --- 1602,1605 ---- From gcc-return-9597-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 22:39:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31712 invoked by alias); 27 Aug 1999 22:39:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31677 invoked from network); 27 Aug 1999 22:39:49 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 27 Aug 1999 22:39:49 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id SAA29482 for ; Fri, 27 Aug 1999 18:39:47 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (root@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id SAA28197 for ; Fri, 27 Aug 1999 18:37:43 -0400 (EDT) Received: (qmail 29126 invoked by uid 500); 27 Aug 1999 22:19:23 -0000 Date: 27 Aug 1999 22:19:23 -0000 Message-ID: <19990827221923.29125.qmail@deer> To: papadopo@shfj.cea.fr CC: gcc@gcc.gnu.org cc: craig@jcb-sc.com In-reply-to: <199908271616.SAA08162@orcanie.shfj.cea.fr> (message from Dimitri PAPADOPOULOS-ORFANOS on Fri, 27 Aug 1999 18:16:37 +0200 (MET DST)) Subject: Re: egcs/Solaris status References: <199908271616.SAA08162@orcanie.shfj.cea.fr> > The program crashes randomly (1 failure out of ~100 runs). Some programs have inherit exposures to random behavior. For example, games that pick random numbers, programs that are sensitive to timing of asynchronous events in their *design* (such as transaction-processing programs), and so on. But even programs that don't have these inherit exposures can have bugs that manifest as random problems due to other factors. Among these other factors are asynchronous *implementations* upon which the program relies, via library routines it uses, or via the underlying system architecture. When working on SPARCs, a substantial source of underlying asynchronous behavior is the register-window mechanism. This mechanism can be triggered at any time, causing memory in the stack to be written (or read), even if the stack frame doesn't belong to the currently active procedure. In particular, if a program has a bug involving an uninitialized variable, and that variable happens to "live" in the stack frame at an appropriate location, it might happen to *normally* end up with the "correct" value *except* when it is asynchronously trashed, before being used, by a register-window spill operation. Debugging this sort of thing is a nightmare. And all it takes to make it start happening, when it never seemed to happen before, is for a new version of a compiler to decide to allocate some variable somewhere else, make a stack frame for one or more procedures (perhaps not directly related to the one containing a bug) smaller or larger, etc. Even keeping everything the same except for the order in which .o files are linked on the command line can make the bug happen more or less often. Ditto for running the exact same executable on a different SPARC implementation -- one that has more or less register files in the CPU, or that has a greater or smaller load, for example. (That doesn't mean a change in frequency of crashes necessarily points to the spill being the trigger -- there are other asynchronous events in most systems, after all. But for straight numerical code a la typical Fortran, for example, I'd look at the window spills first.) Archives of comp.arch (USENET) might provide more info on this problem, and other net resources might exist that offer advice about how to search for the source of a bug that might be triggered by a window spill. tq vm, (burley) From gcc-return-9598-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 22:42:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 608 invoked by alias); 27 Aug 1999 22:42:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 580 invoked from network); 27 Aug 1999 22:42:40 -0000 Received: from windlord.stanford.edu (171.64.12.23) by egcs.cygnus.com with SMTP; 27 Aug 1999 22:42:40 -0000 Received: (qmail 14486 invoked by uid 50); 27 Aug 1999 22:42:34 -0000 To: gcc@gcc.gnu.org Subject: More successful builds, alpha-dec-osf3.2 failure From: Russ Allbery Date: 27 Aug 1999 15:42:34 -0700 Message-ID: Lines: 27 X-Mailer: Gnus v5.4.66/Emacs 19.34 I've successfully bootstrapped gcc 2.95.1 on the following platforms not currently mentioned on the build status page: alpha-dec-osf4.0b rs6000-ibm-aix4.1.4.0 For what it's worth, I've also successfully bootstrapped on the following platforms that are already listed: hppa2.0-hp-hpux10.20 i586-pc-linux-gnulibc1 i686-pc-linux-gnu rs6000-ibm-aix4.2.1.0 mips-sgi-irix6.2 mips-sgi-irix6.4 mips-sgi-irix6.5 sparc-sun-solaris2.5.1 sparc-sun-solaris2.6 sparc-sun-solaris2.7 i386-pc-solaris2.6 gcc 2.95.1 failed to bootstrap (giving assembler errors) on alpha-dec-osf3.2. A more comprehensive report was sent to gcc-bugs@gcc.gnu.org. -- Russ Allbery (rra@stanford.edu) From gcc-return-9599-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 23:21:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3691 invoked by alias); 27 Aug 1999 23:21:24 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3676 invoked from network); 27 Aug 1999 23:21:17 -0000 Received: from front2.grolier.fr (194.158.96.52) by egcs.cygnus.com with SMTP; 27 Aug 1999 23:21:17 -0000 Received: from dimitri.localdomain (ppp-112-173.villette.club-internet.fr [194.158.112.173]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA04587 for ; Sat, 28 Aug 1999 01:21:13 +0200 (MET DST) Received: from club-internet.fr (dimitri.localdomain [127.0.0.1]) by dimitri.localdomain (8.8.7/8.8.7/Dimitri) with ESMTP id BAA01229 for ; Sat, 28 Aug 1999 01:09:39 +0200 Message-ID: <37C71AB3.BEAAA35A@club-internet.fr> Date: Sat, 28 Aug 1999 01:09:39 +0200 From: Dimitri Papadopoulos X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <199908271616.SAA08162@orcanie.shfj.cea.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Russ Allbery wrote: > > Dimitri PAPADOPOULOS-ORFANOS writes: > > > I believe this is a Solaris bug that triggers a crash more or less often > > depending on the use of GNU as/ld vs. Sun as/ld or on the use of > > -fno-strict-aliasing. These options have a small impact on the binary > > files output produced by the GCC. Depending on which option was chosen, > > the program crashes more or less frequently: > > This may be an obvious suggestion, since it's listed in install/specific, > but I haven't seen it mentioned so far in this thread. You *have* made > sure to not install patch 107058-01 or to patchrm it if you had it > installed, correct? > > With that patch installed, make bootstrap fails for me on Solaris 7 with > either an older version of gcc or with Solaris cc as the compiler; I get a > segfault in the middle of the build or comparison failures between stage2 > and stage3. With that patch removed, gcc 2.95.1 bootstraps cleanly and > appears to work fine. Hi, I obviously don't suffer from this bug, because I am bulding Qt with GCC. So GCC is already built. The whole thread is in fact too long - I am sorry for that. It began with problems bulding GCC, then it continued with problems building other programs with GCC. I guess the transition has not been very clear, but for me both issues are related, as building GCC includes testing GCC on some software we use here. In fact, I have built GCC with GNU as/ld (bootstraping with EGCS using itself GNU as/ld and putting GNU as/ld in my PATH and /usr/ccs/bin out of my PATH). I do have 107058-01 installed but this should have no incidence using such a configuration. Thanks, -- Dimitri From gcc-return-9600-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 23:29:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5501 invoked by alias); 27 Aug 1999 23:29:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5482 invoked from network); 27 Aug 1999 23:29:37 -0000 Received: from windlord.stanford.edu (171.64.12.23) by egcs.cygnus.com with SMTP; 27 Aug 1999 23:29:37 -0000 Received: (qmail 14752 invoked by uid 50); 27 Aug 1999 23:29:30 -0000 To: Dimitri Papadopoulos Cc: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <199908271616.SAA08162@orcanie.shfj.cea.fr> <37C71AB3.BEAAA35A@club-internet.fr> From: Russ Allbery In-Reply-To: Dimitri Papadopoulos's message of "Sat, 28 Aug 1999 01:09:39 +0200" Date: 27 Aug 1999 16:29:30 -0700 Message-ID: Lines: 20 X-Mailer: Gnus v5.4.66/Emacs 19.34 Dimitri Papadopoulos writes: > In fact, I have built GCC with GNU as/ld (bootstraping with EGCS using > itself GNU as/ld and putting GNU as/ld in my PATH and /usr/ccs/bin out > of my PATH). I do have 107058-01 installed but this should have no > incidence using such a configuration. I'd double-check your assumption with gcc -print-search-dirs; remember that gcc has an internal list of directories that are searched *before* the user's path is, and on Solaris by default that list contains /usr/ccs/bin. So it's entirely possible for gcc on Solaris to pick up vendor as even if it's nowhere in your path. I realize that you're not having problems in the same place that I was, but you're reporting "impossible" random crashes, which is precisely the symptoms of the problem created by patch 107058-01 at least in my experience. -- Russ Allbery (rra@stanford.edu) From gcc-return-9601-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 23:46:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7856 invoked by alias); 27 Aug 1999 23:46:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7837 invoked from network); 27 Aug 1999 23:46:40 -0000 Received: from front7.grolier.fr (194.158.96.57) by egcs.cygnus.com with SMTP; 27 Aug 1999 23:46:40 -0000 Received: from dimitri.localdomain (ppp-112-173.villette.club-internet.fr [194.158.112.173]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA12981 for ; Sat, 28 Aug 1999 01:46:37 +0200 (MET DST) Received: from club-internet.fr (dimitri.localdomain [127.0.0.1]) by dimitri.localdomain (8.8.7/8.8.7/Dimitri) with ESMTP id BAA01243 for ; Sat, 28 Aug 1999 01:37:32 +0200 Message-ID: <37C7213C.7E799533@club-internet.fr> Date: Sat, 28 Aug 1999 01:37:32 +0200 From: Dimitri Papadopoulos X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <199908271616.SAA08162@orcanie.shfj.cea.fr> <37C71AB3.BEAAA35A@club-internet.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Russ Allbery wrote: > > Dimitri Papadopoulos writes: > > > In fact, I have built GCC with GNU as/ld (bootstraping with EGCS using > > itself GNU as/ld and putting GNU as/ld in my PATH and /usr/ccs/bin out > > of my PATH). I do have 107058-01 installed but this should have no > > incidence using such a configuration. > > I'd double-check your assumption with gcc -print-search-dirs; remember > that gcc has an internal list of directories that are searched *before* > the user's path is, and on Solaris by default that list contains > /usr/ccs/bin. So it's entirely possible for gcc on Solaris to pick up > vendor as even if it's nowhere in your path. > > I realize that you're not having problems in the same place that I was, > but you're reporting "impossible" random crashes, which is precisely the > symptoms of the problem created by patch 107058-01 at least in my > experience. You're right. However, I am sure GNU as/ld are used when building Qt (checked with g++ -v and GCC is setup to use GNU as/ld following the directions in the FAQ). Besides, I have also built Qt on an unpatched machine. What could have happened, though, is GCC itself being built on a 107058-01 patched machine. Although it was built with an EGCS using GNU as/ld, it could have used Sun as/ld to built itself in the last stages. Could this have some incidence? I'll rebuild GCC on a "clean" machine on Monday to get sure. It won't be easy to test wether this changes something though, as my random bug is getting rare - should I add a :-) or a :-( here? Thanks again, -- Dimitri From gcc-return-9602-listarch-gcc=gcc.gnu.org@gcc.gnu.org Fri Aug 27 23:46:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7873 invoked by alias); 27 Aug 1999 23:46:44 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7846 invoked from network); 27 Aug 1999 23:46:41 -0000 Received: from front7.grolier.fr (194.158.96.57) by egcs.cygnus.com with SMTP; 27 Aug 1999 23:46:41 -0000 Received: from dimitri.localdomain (ppp-112-173.villette.club-internet.fr [194.158.112.173]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id BAA12984 for ; Sat, 28 Aug 1999 01:46:39 +0200 (MET DST) Received: from club-internet.fr (dimitri.localdomain [127.0.0.1]) by dimitri.localdomain (8.8.7/8.8.7/Dimitri) with ESMTP id BAA01246 for ; Sat, 28 Aug 1999 01:40:38 +0200 Message-ID: <37C721F6.6808B4B6@club-internet.fr> Date: Sat, 28 Aug 1999 01:40:38 +0200 From: Dimitri Papadopoulos X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <199908271616.SAA08162@orcanie.shfj.cea.fr> <19990827221923.29125.qmail@deer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit craig@jcb-sc.com wrote: > > > The program crashes randomly (1 failure out of ~100 runs). > > Some programs have inherit exposures to random behavior. For example, > games that pick random numbers, programs that are sensitive to timing > of asynchronous events in their *design* (such as transaction-processing > programs), and so on. > > But even programs that don't have these inherit exposures can have > bugs that manifest as random problems due to other factors. > > [...] Thanks for this very complete explanation of what seems to be the most probable cause for this problem. If the bug is not in the compiler or Solaris, it's good news! > In particular, if a program has a bug involving an uninitialized > variable, and that variable happens to "live" in the stack frame > at an appropriate location, it might happen to *normally* end up > with the "correct" value *except* when it is asynchronously trashed, > before being used, by a register-window spill operation. > > [...] Just two questions though. I believe Qt is Purified. Doesn't Purify detect unitialized variables? Also, is it possible that 'this' is not initialized? The "corrupted" variable is 'this'. Qt and its examples are very prone to other asynchronous events - this is a GUI toolkit. So the cause could be anything indeed :( > Archives of comp.arch (USENET) might provide more info on this problem, > and other net resources might exist that offer advice about how to > search for the source of a bug that might be triggered by a window spill. > > [...] I'll have a look there. But the whole problem seems rather complicated :( And I was able to reproduce the problem only once in ~200 runs today. Maybe because my machine was not under heavy load? I'll just have to forget the whole thing and upgrade to GCC 2.95.1, I guess. Our Qt programs are not that mission-critical... Regards, -- Dimitri From gcc-return-9603-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 00:15:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12263 invoked by alias); 28 Aug 1999 00:15:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12247 invoked from network); 28 Aug 1999 00:15:24 -0000 Received: from cantva.canterbury.ac.nz (132.181.30.3) by egcs.cygnus.com with SMTP; 28 Aug 1999 00:15:24 -0000 Received: from CONVERSION-DAEMON by its.canterbury.ac.nz (PMDF V5.2-32 #39167) id <01JFATU98VJK9BWLOM@its.canterbury.ac.nz> for egcs@egcs.cygnus.com; Sat, 28 Aug 1999 12:15:21 +1200 (NEW ZEALAND STANDARD TIME) Received: from andromeda.elec.canterbury.ac.nz (andromeda.elec.canterbury.ac.nz [132.181.50.31]) by its.canterbury.ac.nz (PMDF V5.2-32 #39167) with ESMTP id <01JFATU91MCC9BVRA4@its.canterbury.ac.nz>; Sat, 28 Aug 1999 12:15:21 +1200 (NEW ZEALAND STANDARD TIME) Received: from ongaonga.elec.canterbury.ac.nz (ongaonga [132.181.54.69]) by andromeda.elec.canterbury.ac.nz (8.9.3/8.9.3) with ESMTP id MAA18886; Sat, 28 Aug 1999 12:15:15 +1200 (NZST) Received: (from mph@localhost) by ongaonga.elec.canterbury.ac.nz (8.9.3/8.9.3) id MAA18792; Sat, 28 Aug 1999 12:15:02 +1200 Date: Sat, 28 Aug 1999 12:15:02 +1200 (NZST) From: Michael Hayes Subject: New const function detection code and infinite loops. In-reply-to: To: Jan Hubicka Cc: egcs@egcs.cygnus.com Message-id: <14279.10544.594708.813751@ongaonga.elec.canterbury.ac.nz> MIME-version: 1.0 (generated by tm-edit 7.108) X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Content-type: text/plain; charset=US-ASCII References: Jan Hubicka writes: > So I can send a patch if neccesary. Is there any way how to detect > bounded loops? (loop.c does it, is this information available somewhere?) I've got some code, if you are interested, that I'm tidying up for submission that tries to estimate the maximum number of estimations for "well-behaved" loops. However, it relies on information gathered during strength reduction. Michael. From gcc-return-9604-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 00:21:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13311 invoked by alias); 28 Aug 1999 00:20:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13293 invoked from network); 28 Aug 1999 00:20:53 -0000 Received: from garfield.dis.com (199.4.97.30) by egcs.cygnus.com with SMTP; 28 Aug 1999 00:20:53 -0000 Received: from garfield (199.4.97.30) by garfield.dis.com (EMWAC SMTPRS 0.81) with SMTP id ; Fri, 27 Aug 1999 17:20:50 -0700 Message-Id: <4.1.19990827171727.00c5a960@garfield.dis.com> X-Sender: mark@garfield.dis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 27 Aug 1999 17:20:48 -0700 To: law@cygnus.com From: Mark Klein Subject: Re: HARD_REGNO_MODE_OK on PA-RISC (revisited) Cc: gcc@gcc.gnu.org In-Reply-To: <9017.935791187@upchuck.cygnus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 03:59 PM 8/27/99 -0600, Jeffrey A Law wrote: >My queue is over 200 patches deep. And unfortunately MPE isn't anywhere near >the top of the list. Simply a matter of priorities. OK. I'll keep tracking what you've got (thank heaven I ported CVS to MPE). Let me know when you want me to repost them and I'll do so. >:-) I did something similar already. We're still beating on it internally >before we contribute it. For sake of argument, here's mine. I reformatted it a bit to understand it better. The only real changes are to handle the long double: struct rtx_def * function_arg(cum, mode, type, named) const CUMULATIVE_ARGS *cum; enum machine_mode mode; tree type; int named; { rtx reg = 0; int basereg1 = 0; int basereg2 = 0; /* * See if there is at least one argument register still available. */ if (4 >= cum->words + FUNCTION_ARG_SIZE (mode, type)) { if (!TARGET_PORTABLE_RUNTIME || type == 0 || !FLOAT_MODE_P (mode) || TARGET_SOFT_FLOAT || cum->nargs_prototype > 0) { if (FUNCTION_ARG_SIZE (mode, type) > 2) { /* * We're dealing with an argument greater than 2 words. * It must be passed in the frame by reference. */ return 0; } if (FUNCTION_ARG_SIZE (mode, type) > 1) { /* * This is a multi-word parameter. If this is either a direct * call or the portable runtime and we're dealing with the * hardware FPU, place the argument in the argument into the * correct FARG, otherwise put it in a general register. */ if ((!cum->indirect || TARGET_PORTABLE_RUNTIME) && (mode) == DFmode && !TARGET_SOFT_FLOAT) basereg1 = (cum->words ? 38 : 34); else basereg1 = (cum->words ? 23 : 25); } else { /* * This is a single-word parameter. If this is either a direct * call or the portable runtime and we're dealing with the * hardware FPU, place the argument into the correct FARG, * otherwise put it into a general register. */ if ((!cum->indirect || TARGET_PORTABLE_RUNTIME) && (mode) == SFmode && !TARGET_SOFT_FLOAT) basereg1 = (32 + 2 * cum->words); else basereg1 = (27 - cum->words - FUNCTION_ARG_SIZE(mode, type)); } /* * Generate the REG rtx for the current parameter. */ reg = gen_rtx_REG (mode, basereg1); } else { /* * We need to place the argument in both floating args as well * as the general args. */ if (FUNCTION_ARG_SIZE (mode, type) > 2) { /* * We're dealing with an argument greater than 2 words. * It must be passed in the frame by reference. */ return 0; } if (FUNCTION_ARG_SIZE (mode, type) > 1) { basereg1 = (cum->words ? 38 : 34); basereg2 = (cum->words ? 23 : 25); } else { basereg1 = (32 + 2 * cum->words); basereg2 = (27 - cum->words - FUNCTION_ARG_SIZE (mode, type)); } reg = gen_rtx_PARALLEL (mode, gen_rtvec(2, gen_rtx_EXPR_LIST (VOIDmode, gen_rtx_REG (mode, basereg1), const0_rtx), gen_rtx_EXPR_LIST (VOIDmode, gen_rtx_REG (mode, basereg2), const0_rtx))); } } return reg; } /DIS/GNU/src/egcs-ss/gcc/config/pa(134): -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available From gcc-return-9605-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 00:27:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14668 invoked by alias); 28 Aug 1999 00:26:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14632 invoked from network); 28 Aug 1999 00:26:28 -0000 Received: from smtp1.cern.ch (137.138.128.38) by egcs.cygnus.com with SMTP; 28 Aug 1999 00:26:28 -0000 Received: from pcep-jamie.cern.ch (pcep-jamie.cern.ch [137.138.38.126]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id CAA24574; Sat, 28 Aug 1999 02:26:25 +0200 (MET DST) Received: (from jamie@localhost) by pcep-jamie.cern.ch (8.9.3/8.9.3) id CAA09575; Sat, 28 Aug 1999 02:26:24 +0200 Date: Sat, 28 Aug 1999 02:26:24 +0200 From: Jamie Lokier To: Joern Rennecke Cc: tromey@cygnus.com, gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter Message-ID: <19990828022624.A9566@pcep-jamie.cern.ch> References: <87hfllte1m.fsf@cygnus.com> <199908271728.SAA32203@phal.cygnus.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <199908271728.SAA32203@phal.cygnus.co.uk>; from Joern Rennecke on Fri, Aug 27, 1999 at 06:28:31PM +0100 Is there a possibility to have GCC emit fixup tables so that GC roots can be found unambiguously? Something that's independent of any particular GC implementation. I'm thinking PC-based tables a bit like the .eh_frame tables, but different. Like .eh_frame, the efficiency hit on main line code should be minimal. It would be a matter of mapping certain PC values to register & stack maps, where the maps indicate which registers & stack slots contain live GC roots, and (perhaps) the types of the GC roots. If it's done by code fragments like exceptions (but the stack isn't actually unwound for GC), even the more aggressive pointer optimisations can be permitted provided there's enough information to regenerate the GC roots in fixup code. -- Jamie From gcc-return-9606-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 00:32:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16029 invoked by alias); 28 Aug 1999 00:32:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16009 invoked from network); 28 Aug 1999 00:32:06 -0000 Received: from mailhost.uni-koblenz.de (@141.26.64.1) by egcs.cygnus.com with SMTP; 28 Aug 1999 00:32:06 -0000 Received: from lappi.waldorf-gmbh.de (cacc-14.uni-koblenz.de [141.26.131.14]) by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id CAA17156 for ; Sat, 28 Aug 1999 02:32:01 +0200 (MET DST) Received: (from ralf@localhost) by lappi.waldorf-gmbh.de (8.9.3/8.9.3) id NAA00887; Fri, 27 Aug 1999 13:44:23 +0200 Date: Fri, 27 Aug 1999 13:44:23 +0200 From: Ralf Baechle To: Mark Mitchell Cc: jbuck@synopsys.COM, jason@cygnus.com, drepper@cygnus.com, george@moberg.com, kriol@fnal.gov, gcc@gcc.gnu.org, libc-alpha@sourceware.cygnus.com Subject: Re: Help: Unwinding the C++ stack...throw, longjmp & threads Message-ID: <19990827134423.A849@uni-koblenz.de> References: <19990824152334N.mitchell@codesourcery.com> <199908242329.QAA02362@atrus.synopsys.com> <19990824171319F.mitchell@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <19990824171319F.mitchell@codesourcery.com>; from Mark Mitchell on Tue, Aug 24, 1999 at 05:13:19PM -0700 X-Accept-Language: de,en,fr On Tue, Aug 24, 1999 at 05:13:19PM -0700, Mark Mitchell wrote: > Good point. But, as you say, they're already building a special > glibc. I think that only C++/Ada/Java/etc. applications that use > exception-handling would need the extra data; obviously, that's a > pretty small set or glibc would *already* be built with -fexceptions. > > There may be systems on which glibc is used, but statically linked. > There, I would see more of an issue, as every binary would grow. (For > example, this might be true if glibc were ported to a system without > shared library support in binutils.) But, I think we should cross > that bridge when we come to it. MIPS64 is such a system since gas cannot assemble 64 ABI PIC code. The second thing is that I'd like to use glibc for standalone programs running directly on the firmware, ARC(S) or other, where shared libraries are not really an option. Ralf From gcc-return-9607-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 00:40:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17898 invoked by alias); 28 Aug 1999 00:40:29 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17882 invoked from network); 28 Aug 1999 00:40:28 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 28 Aug 1999 00:40:28 -0000 Received: from ferrule.cygnus.com. (ferrule.cygnus.com [205.180.230.166]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with SMTP id RAA22089; Fri, 27 Aug 1999 17:40:25 -0700 (PDT) Received: by ferrule.cygnus.com. (SMI-8.6/SMI-SVR4) id RAA01449; Fri, 27 Aug 1999 17:40:25 -0700 Date: Fri, 27 Aug 1999 17:40:25 -0700 Message-Id: <199908280040.RAA01449@ferrule.cygnus.com.> From: Tom Tromey To: Jamie Lokier Cc: Joern Rennecke , tromey@cygnus.com, gcc@gcc.gnu.org Subject: Re: C++ Garbage Collecter In-Reply-To: <19990828022624.A9566@pcep-jamie.cern.ch> References: <87hfllte1m.fsf@cygnus.com> <199908271728.SAA32203@phal.cygnus.co.uk> <19990828022624.A9566@pcep-jamie.cern.ch> X-Zippy: I always have fun because I'm out of my mind!!! X-Attribution: Tom >>>>> "Jamie" == Jamie Lokier writes: Jamie> Is there a possibility to have GCC emit fixup tables so that GC Jamie> roots can be found unambiguously? Something that's independent Jamie> of any particular GC implementation. Yes. I've even read a paper where the authors implemented this approach (I don't recall whether they used gcc). Their tables had enough information so that the collector could unravel pointer hiding by the compiler. Much of their work dealt with finding ways to compact the tables to reduce space overhead. I can't find the paper right now (I recently moved, and everything seems lost). I think something along these lines is necessary if you want a precise, copying GC (as opposed to a mostly-copying GC). Whether anybody really wants this with gcc-generated code, I don't know. For a conservative GC, it is probably easier and more efficient to just stuff the object's base pointer on the stack somewhere, at least until all uses of derived values are dead -- keeping values "live" (meaning GC-visible, not the same as gcc's notion of liveness) too long is another GC issue in code the compiler generates. In some situations you really want the compiler to null out (or somehow inform the GC of the deadness of) all references to an object that will no longer be used. Tom From gcc-return-9608-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 00:52:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19605 invoked by alias); 28 Aug 1999 00:52:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19590 invoked from network); 28 Aug 1999 00:52:54 -0000 Received: from ha1.rdc1.md.home.com (HELO mail.rdc1.md.home.com) (imail@24.2.2.66) by egcs.cygnus.com with SMTP; 28 Aug 1999 00:52:54 -0000 Received: from home.com ([24.3.46.228]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990828005253.VRPN20194.mail.rdc1.md.home.com@home.com> for ; Fri, 27 Aug 1999 17:52:53 -0700 Message-ID: <37C7338B.79DC91BF@home.com> Date: Fri, 27 Aug 1999 20:55:39 -0400 From: Kevin Atkinson X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i586) X-Accept-Language: en MIME-Version: 1.0 To: egcs@egcs.cygnus.com Subject: How to be Garbage Collector safe. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit After asking about if gcc is garbage collector safe I got two basic answers: Jeffrey A Law answer was: No, because "I *know* GCC will create situations which will spoof a garbage collector." However, Per Bothner , answered with, it is a theoretical problem, but in practices these hypothetical situations don't come up. So my question is: What can *I* do as a C++ programmer to make sure the optimizer doesn't screw with my variables like jeff said. Would always having a pointer marked with volatile do the trick such as: class Y; class X { volatile Y * ptr; ... }; do the trick. What other things can I do to make sure that I don't have dangling reference do to premature garbage collections? -- Kevin Atkinson kevinatk@home.com http://metalab.unc.edu/kevina/ From gcc-return-9609-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 03:54:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30496 invoked by alias); 28 Aug 1999 03:54:35 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30481 invoked from network); 28 Aug 1999 03:54:31 -0000 Received: from out4.ibm.net (165.87.194.239) by egcs.cygnus.com with SMTP; 28 Aug 1999 03:54:31 -0000 Received: from markelbr (slip129-37-91-119.sc.us.ibm.net [129.37.91.119]) by out4.ibm.net (8.8.5/8.6.9) with ESMTP id DAA107668 for ; Sat, 28 Aug 1999 03:54:28 GMT Message-Id: <199908280354.DAA107668@out4.ibm.net> From: "Mark E." To: gcc@gcc.gnu.org Date: Fri, 27 Aug 1999 23:54:36 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Question about .gnu.linkonce config Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12a) Hi folks, I have a question about the changes needed to support .gnu.linkonce for DJGPP now that the binutils changes have made. I'd like to know if I need the following snippet from the typical UNIQUE_SECTION that supports .gnu.linkonce (backslashes deleted): if (! DECL_ONE_ONLY (DECL) && 0) { prefix = "."; if (TREE_CODE (DECL) == FUNCTION_DECL) prefix = ".text."; else if (DECL_READONLY_SECTION (DECL, RELOC)) prefix = ".rodata."; else prefix = ".data."; } else if (TREE_CODE (DECL) == FUNCTION_DECL) given that UNIQUE_SECTION_P is also typically defined as: #define UNIQUE_SECTION_P (DECL_ONE_ONLY (DECL)) Am I right? My testing seems to confirm this, but it could also be I'm not using the right test cases. --- Mark Elbrecht, snowball3@bigfoot.com http://snowball.frogspace.net/ From gcc-return-9610-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 06:05:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4654 invoked by alias); 28 Aug 1999 06:05:53 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4639 invoked from network); 28 Aug 1999 06:05:51 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 28 Aug 1999 06:05:51 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id XAA10145; Fri, 27 Aug 1999 23:57:48 -0600 X-Mailer: exmh version 2.0.2 To: Zack Weinberg cc: gcc@gcc.gnu.org Subject: Re: init_mov_optab obsolete? Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 23 Aug 1999 22:35:26 PDT. <199908240535.WAA00508@zack.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 23:57:48 -0600 Message-ID: <10142.935819868@upchuck.cygnus.com> From: Jeffrey A Law In message <199908240535.WAA00508@zack.bitmover.com>you write: > > If EXTRA_CC_MODES is defined, genemit.c writes out a special function > called init_mov_optab that adds entries to mov_optab for patterns that > move those modes around. However, it appears to me that > init_all_optabs (generated by genopinit.c) will set up those entries > anyway. > > Am I right, and if so, can we kill it? It's not doing any harm, but > it is confusing when you're trying to unravel what the md processors > do. > > (N.B. No current machine description actually defines patterns to move > extra cc modes around.) Actually, I do not think the code in genopinit.c works correctly in the presence of CC modes. But I think the code in genemit.c does work correctly for the extra CC modes. Before killing the code I'd like to have some reasonable expectation that the code we leave will actually work. Don't let the fact that no ports define patterns to move extra CC modes cloud the issue. We will need it to effectively support some stuff in the PA2.0 architecture. I just haven't written the code yet ;-0 jeff From gcc-return-9611-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 06:19:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5887 invoked by alias); 28 Aug 1999 06:19:06 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5872 invoked from network); 28 Aug 1999 06:19:04 -0000 Received: from dnai-216-15-97-161.cust.dnai.com (HELO zack.bitmover.com) (216.15.97.161) by egcs.cygnus.com with SMTP; 28 Aug 1999 06:19:04 -0000 Received: from zack.bitmover.com (localhost [127.0.0.1]) by zack.bitmover.com (8.9.3/8.9.3) with ESMTP id XAA15484; Fri, 27 Aug 1999 23:12:52 -0700 Message-Id: <199908280612.XAA15484@zack.bitmover.com> To: law@cygnus.com Cc: gcc@gcc.gnu.org Subject: Re: init_mov_optab obsolete? In-Reply-To: Your message of "Fri, 27 Aug 1999 23:57:48 MDT." <10142.935819868@upchuck.cygnus.com> Date: Fri, 27 Aug 1999 23:12:52 -0700 From: Zack Weinberg Jeffrey A Law wrote: > In message <199908240535.WAA00508@zack.bitmover.com>you write: > > > > If EXTRA_CC_MODES is defined, genemit.c writes out a special function > > called init_mov_optab that adds entries to mov_optab for patterns that > > move those modes around. However, it appears to me that > > init_all_optabs (generated by genopinit.c) will set up those entries > > anyway. > > > > Am I right, and if so, can we kill it? It's not doing any harm, but > > it is confusing when you're trying to unravel what the md processors > > do. > > > > (N.B. No current machine description actually defines patterns to move > > extra cc modes around.) > > Actually, I do not think the code in genopinit.c works correctly in > the presence of CC modes. But I think the code in genemit.c does > work correctly for the extra CC modes. > > Before killing the code I'd like to have some reasonable expectation > that the code we leave will actually work. > > Don't let the fact that no ports define patterns to move extra CC > modes cloud the issue. We will need it to effectively support some > stuff in the PA2.0 architecture. I just haven't written the code > yet ;-0 I'm pretty sure init_all_optabs will generate either a correct initialization or no initialization at all. Can you show me a sample pattern that should be recognized as an extra-CC-mode move? Then I will make sure genopinit.c does the right thing. zw From gcc-return-9612-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 08:59:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29286 invoked by alias); 28 Aug 1999 08:59:14 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29262 invoked from network); 28 Aug 1999 08:59:06 -0000 Received: from unknown (HELO stargate.astr.lu.lv) (195.13.132.244) by egcs.cygnus.com with SMTP; 28 Aug 1999 08:59:06 -0000 Received: from hal (unverified [195.13.134.67]) by stargate.astr.lu.lv (EMWAC SMTPRS 0.83) with SMTP id ; Sat, 28 Aug 1999 11:59:20 +0300 From: Andris Pavenis Organization: AI LU To: "DANNIELSIMON" , Subject: Re: Precise directions for installation Date: Sat, 28 Aug 1999 11:53:03 +0000 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain References: <000f01bef0ef$21c8a480$4b1c0a3f@f1i4z3> MIME-Version: 1.0 Message-Id: <99082811590000.01238@hal> Content-Transfer-Encoding: 8bit You should get binaries but not sources. Look GCC homepage for binaries of Windows related ports of GCC and related tools: http://gcc.gnu.org http://sourceware.cygnus.com/cygwin/ Or take a look to DJGPP: http://www.delorie.com/djgpp/ (It's not Win32, but also works under Win9X for example with long file names) Andris On Sat, 28 Aug 1999, DANNIELSIMON wrote: > >%_Hi, > > I am trying to install GCC on a PII 400 Win 98 machine. > > I have downloaded the latest version and put in a file named GCC. > I have also downloaded bzip2 and decompressed the GCC file. > > Now I have a 54MB file but can not install or run it. The online instructions ofer little help, > > I would appreciate a detailed instruction set to get me going. > > Please feel free to ask for more info. > > Thanks, > > Dan Simon > > The quicker I get this installed the better. > > > ---------------------------------------- Content-Type: text/html; name="unnamed" Content-Transfer-Encoding: quoted-printable Content-Description: ---------------------------------------- From gcc-return-9613-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 10:44:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7574 invoked by alias); 28 Aug 1999 10:44:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7551 invoked from network); 28 Aug 1999 10:44:13 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 28 Aug 1999 10:44:13 -0000 Received: from alphard (alphard [128.130.111.37]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id MAA05403; Sat, 28 Aug 1999 12:43:57 +0200 (MET DST) Date: Sat, 28 Aug 1999 12:43:55 +0200 (MET DST) From: Gerald Pfeifer To: gcc@gcc.gnu.org cc: Russ Allbery , Paul Eggert Subject: GCC 2.95.x: Major problems on Solaris (was: Lost specific.html FAQEntry) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 27 Aug 1999, Russ Allbery wrote: > FYI, GNU ld from binutils 2.9.1 fails to successfully link Perl 5.005_03 > on Solaris 2.6. I haven't tried other versions of Solaris. (Perl's hint > files try to keep you from using GNU ld on Solaris, saying that it won't > work correctly, and they are apparently entirely correct since overriding > that results in a non-functional Perl build.) Russ, thanks for your data points concerning Solaris! Folks, we have had an incredible number of problem reports concerning Solaris (mostly Solaris 7, binutils vs vendor tools, Sun make vs gmake...) for 2.95.x. Here is what we I think we should do about that: 1. I have already performed a couple of updates to http://gcc.gnu.org/install/ but it seems we still need some further ones. Patches and hints are most welcome, as are updates to existing stuff. 2. Shall we actually recommend against GNU ld for Solaris targets? 3. Which versions of Sun make are sufficiently POSIX compliant for a srcdir != objdir bootstrap? Which are not? 4. Perhaps there are GNU make specific features in some of our Makefiles? I vaguely remember some portability(?) patches several months ago, which were supposed to allow for srcdir != objdir builds with Sun make. 5. Has someone experiencing these problems already submitted bug reports to the binutils developers resp. Sun? Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9614-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 11:27:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11762 invoked by alias); 28 Aug 1999 11:27:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11742 invoked from network); 28 Aug 1999 11:27:00 -0000 Received: from mail.provi.de (193.98.9.7) by egcs.cygnus.com with SMTP; 28 Aug 1999 11:27:00 -0000 Received: from kahlert.linux.provi.de ([195.222.239.44] helo=keksy.linux.provi.de) by mail.provi.de with esmtp (Exim 2.12 #1) id 11KgdP-0004vm-00 for egcs@egcs.cygnus.com; Sat, 28 Aug 1999 13:26:59 +0200 Received: (from martin@localhost) by keksy.linux.provi.de (8.8.8/8.8.8) id NAA00385 for egcs@egcs.cygnus.com; Sat, 28 Aug 1999 13:30:48 +0200 Date: Sat, 28 Aug 1999 13:30:48 +0200 From: martin.kahlert@provi.de Message-Id: <199908281130.NAA00385@keksy.linux.provi.de> To: egcs@egcs.cygnus.com Subject: g77 performance on ALPHA Hi, i participate in the beta test of Compaq's fortran compiler for Linux-Alpha. I have a EV56 sytem running at 530MHz. The result is not too good for g77 (2.95.1 release). I tested a big (>1MB source) code (electrical analog circuit simulator) and Compaq's compiler produces more than twice the performance of g77. So i tested with a small daxpy operation: SUBROUTINE DAXPY(N,ALPHA,X,I1,Y,I2) IMPLICIT NONE INTEGER*4 N,I,I1,I2 REAL*8 ALPHA,X(N),Y(N) DO I=1, N Y(I)=Y(I)+ALPHA*X(I) ENDDO RETURN END My main program looks like that: IMPLICIT NONE INTEGER*4 N,NLOOP,I PARAMETER(N=1000,NLOOP=100000) REAL*4 TS,TE,TARR(2),ETIME REAL*8 X(N),Y(N),OPS DO I=1, N X(I) = 1.1D0 Y(I) = 1.1D0 ENDDO TS = ETIME(TARR) DO I=1, NLOOP CALL DAXPY(N,1.01D0,X,1,Y,1) ENDDO TE = ETIME(TARR) OPS = (1D-6*N)*(NLOOP*2D0) WRITE(*,*) OPS/(TE-TS),' MFlops' END Result: g77 -O3 -o main main.f daxpy.f ./main 72.75 MFlops fort -O -fast -o main main.f daxpy.f ./main 191.94 MFlops (The handcoded asm-daxpy of Mr. Goto gets 378.55 MFlops) g77 -O3 -S daxpy.f results in this: .file 1 "dxpy.f" .set noat .set noreorder .arch ev56 .text .align 5 .globl daxpy_ .ent daxpy_ daxpy_: .frame $30,0,$26,0 $daxpy_..ng: .prologue 0 ldl $1,0($16) subl $1,1,$1 fnop blt $1,$L2 ldt $f12,0($17) subq $1,1,$2 .align 4 $L6: ldt $f10,0($18) ldt $f11,0($20) mov $2,$1 addq $18,8,$18 mult $f12,$f10,$f10 addl $1,$31,$1 subq $2,1,$2 addt $f11,$f10,$f11 stt $f11,0($20) addq $20,8,$20 bge $1,$L6 $L2: ret $31,($26),1 .end daxpy_ .ident "GCC: (GNU) 2.95.1 19990816 (release)" The loop isn't unrolled with -funroll-loops, either. Using -funroll-all-loops, we get .file 1 "dxpy.f" .set noat .set noreorder .arch ev56 .text .align 5 .globl daxpy_ .ent daxpy_ daxpy_: .frame $30,0,$26,0 $daxpy_..ng: .prologue 0 ldl $1,0($16) subl $1,1,$1 fnop blt $1,$L2 ldt $f12,0($17) subq $1,1,$2 .align 4 $L6: ldt $f10,0($18) ldt $f11,0($20) subq $2,1,$3 addl $2,$31,$1 mult $f12,$f10,$f10 addt $f11,$f10,$f11 stt $f11,0($20) blt $1,$L2 ldt $f10,8($18) ldt $f11,8($20) addl $3,$31,$1 nop mult $f12,$f10,$f10 subq $2,2,$3 addt $f11,$f10,$f11 nop stt $f11,8($20) blt $1,$L2 ldt $f10,16($18) ldt $f11,16($20) addl $3,$31,$1 mult $f12,$f10,$f10 subq $2,3,$3 addt $f11,$f10,$f11 stt $f11,16($20) blt $1,$L2 ldt $f10,24($18) ldt $f11,24($20) addl $3,$31,$1 addq $18,32,$18 mult $f12,$f10,$f10 subq $2,4,$2 addt $f11,$f10,$f11 stt $f11,24($20) addq $20,32,$20 bge $1,$L6 $L2: ret $31,($26),1 .end daxpy_ .ident "GCC: (GNU) 2.95.1 19990816 (release)" This results in even worse 65.9368963 MFlops. The code of Compaq's compiler looks quite different: .file 1 "dxpy.f" .loc 1 1 # 1 SUBROUTINE DAXPY(N,ALPHA,X,S1,Y,S2) .globl daxpy_ .ent daxpy_ .loc 1 1 daxpy_: # 000001 .frame $sp, 0, $26 .prologue 0 .loc 1 6 # 2 IMPLICIT NONE # 3 INTEGER*4 N,I,S1,S2 # 4 REAL*8 ALPHA,X(N),Y(N) # 5 # 6 DO I=1, N ldl $1, ($16) # 000006 ble $1, lab$0001 .loc 1 7 # 7 Y(I)=Y(I)+ALPHA*X(I) ldt $f0, ($17) # 000007 .loc 1 6 cmple $1, 3, $16 # 000006 bne $16, L$9 lab$0004: .loc 1 7 ldt $f1, ($18) # 000007 ldt $f10, 8($18) ldt $f11, 16($18) ldt $f12, 24($18) ldt $f13, ($20) ldt $f14, 8($20) ldt $f15, 16($20) ldt $f16, 24($20) mult $f0, $f1, $f1 .loc 1 6 lda $1, -4($1) # 000006 .loc 1 7 mult $f0, $f10, $f10 # 000007 mult $f0, $f11, $f11 .loc 1 6 cmple $1, 3, $4 # 000006 lda $18, 32($18) .loc 1 7 mult $f0, $f12, $f12 # 000007 addt $f13, $f1, $f1 .loc 1 6 lda $20, 32($20) # 000006 .loc 1 7 addt $f14, $f10, $f10 # 000007 addt $f15, $f11, $f11 addt $f16, $f12, $f12 stt $f1, -32($20) stt $f10, -24($20) stt $f11, -16($20) stt $f12, -8($20) .loc 1 6 beq $4, lab$0004 # 000006 ble $1, lab$0001 unop L$9: .loc 1 7 ldt $f17, ($18) # 000007 ldt $f18, ($20) .loc 1 6 lda $1, -1($1) # 000006 lda $18, 8($18) lda $20, 8($20) .loc 1 7 mult $f0, $f17, $f17 # 000007 addt $f18, $f17, $f17 unop stt $f17, -8($20) .loc 1 6 bgt $1, L$9 # 000006 .loc 1 10 # 8 ENDDO # 9 RETURN # 10 END lab$0001: # 000010 ret ($26) .end daxpy_ So, how could g77 be improved most easily? Is it a problem with the Haifa-scheduler? It seems to me that gcc can't take that much advantage from unrolling like Compaq's compiler. Any thoughts? Martin. From gcc-return-9615-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 15:41:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18547 invoked by alias); 28 Aug 1999 15:41:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18532 invoked from network); 28 Aug 1999 15:41:25 -0000 Received: from imo28.mx.aol.com (198.81.17.72) by egcs.cygnus.com with SMTP; 28 Aug 1999 15:41:25 -0000 Received: from N8TM@aol.com by imo28.mx.aol.com (mail_out_v22.4.) id eTKAa22755 (8018); Sat, 28 Aug 1999 11:40:25 -0400 (EDT) From: N8TM@aol.com Message-ID: <91e2f005.24f95ce8@aol.com> Date: Sat, 28 Aug 1999 11:40:24 EDT Subject: Re: g77 performance on ALPHA To: martin.kahlert@provi.de, egcs@egcs.cygnus.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows sub 15 In a message dated 8/28/99 3:28:13 AM PST, martin.kahlert@provi.de writes: > So, how could g77 be improved most easily? > Is it a problem with the Haifa-scheduler? It seems to me that gcc > can't take that much advantage from unrolling like Compaq's compiler. As your code shows, gcc/g77 schedulers, either the old one or Haifa, don't do much for pipelined processors which lack out-of-order execution or shadow register re-mapping. They do fairly well on several out-of-order processors. For example, my g77 code speeded up more with a change from R10000 to R12000 processor than the MipsPro code did, and I'm getting generally 80% of the performance from g77 which I get from MipsPro f90 with a great deal of array syntax optimization. The trend in some of the processor families has been to make use of OOO etc. to enable fast execution of simple object code. As the gnu compilers are required to perform well on such processors, including those which have a small set of registers directly available to the program, I suppose it's unlikely that good performance will be obtained where such specialized code generation is needed. The Pentium II processor runs quite well with the -mpentiumpro option, which is the one which generates code compatible with processors back to 486, but without skewing scheduling toward the older models. This is particularly true of code which doesn't spend much time in tight little loops. A trend which goes along with the development of processor families is that the compilers are tuned for the model which has the largest customer base paying current support contracts and buying compilers. For example, the current MipsPro compilers have lost performance on the last Mips models which lack OOO, even though the architecture switches are retained. g77 never got even 40% of the speed of the chip vendor's compilers on those older models, and I'm sure that the vendors weren't thinking of g77 when they developed better hardware which depends less on code tuning. If the resources were available, I would rather see effort spent on compiler transformations such as outer unrolling than on targeting specific CPU models. Tim tprince@computer.org From gcc-return-9616-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 16:39:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22336 invoked by alias); 28 Aug 1999 16:39:35 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22318 invoked from network); 28 Aug 1999 16:39:34 -0000 Received: from ne.mediaone.net (HELO chmls05.mediaone.net) (24.128.1.70) by egcs.cygnus.com with SMTP; 28 Aug 1999 16:39:34 -0000 Received: from moshier.ne.mediaone.net (moshier.ne.mediaone.net [24.218.56.120]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id MAA09811; Sat, 28 Aug 1999 12:39:16 -0400 (EDT) Date: Sat, 28 Aug 1999 12:39:17 -0400 (EDT) From: Stephen L Moshier X-Sender: moshier@moshier.ne.mediaone.net Reply-To: moshier@mediaone.net To: Gerald Pfeifer cc: gcc@gcc.gnu.org Subject: Re: GCC 2.95.x: Major problems on Solaris Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 3. Which versions of Sun make are sufficiently POSIX compliant for a srcdir != objdir bootstrap? Which are not? None, between SunOS 4.0 and 5.2.7. Forget it. Get GNU make. From gcc-return-9617-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 18:44:13 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30457 invoked by alias); 28 Aug 1999 18:44:12 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30442 invoked from network); 28 Aug 1999 18:44:11 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 28 Aug 1999 18:44:11 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA19218; Sat, 28 Aug 1999 11:44:10 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id LAA32169; Sat, 28 Aug 1999 11:44:10 -0700 Date: Sat, 28 Aug 1999 11:44:10 -0700 From: Richard Henderson To: martin.kahlert@provi.de Cc: egcs@egcs.cygnus.com Subject: Re: g77 performance on ALPHA Message-ID: <19990828114410.A29542@cygnus.com> References: <199908281130.NAA00385@keksy.linux.provi.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199908281130.NAA00385@keksy.linux.provi.de>; from martin.kahlert@provi.de on Sat, Aug 28, 1999 at 01:30:48PM +0200 On Sat, Aug 28, 1999 at 01:30:48PM +0200, martin.kahlert@provi.de wrote: > So i tested with a small daxpy operation: > SUBROUTINE DAXPY(N,ALPHA,X,I1,Y,I2) > IMPLICIT NONE > INTEGER*4 N,I,I1,I2 > REAL*8 ALPHA,X(N),Y(N) > > DO I=1, N > Y(I)=Y(I)+ALPHA*X(I) > ENDDO > RETURN > END [...] > The loop isn't unrolled with -funroll-loops, either. Nope. We don't know how to efficiently unroll loops with non-constant bounds. We don't try unless forced ... > Using -funroll-all-loops, we get... ... at which point we generate the somewhat horid code you saw. r~ From gcc-return-9618-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 19:27:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3610 invoked by alias); 28 Aug 1999 19:27:05 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3595 invoked from network); 28 Aug 1999 19:27:02 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 28 Aug 1999 19:27:02 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id VAA15847; Sat, 28 Aug 1999 21:25:22 +0200 Message-ID: <37C837A1.816BDB08@moene.indiv.nluug.nl> Date: Sat, 28 Aug 1999 21:25:21 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: Richard Henderson CC: martin.kahlert@provi.de, egcs@egcs.cygnus.com Subject: Re: g77 performance on ALPHA References: <199908281130.NAA00385@keksy.linux.provi.de> <19990828114410.A29542@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Richard Henderson wrote: > On Sat, Aug 28, 1999 at 01:30:48PM +0200, martin.kahlert@provi.de wrote: > > So i tested with a small daxpy operation: > > SUBROUTINE DAXPY(N,ALPHA,X,I1,Y,I2) > > IMPLICIT NONE > > INTEGER*4 N,I,I1,I2 > > REAL*8 ALPHA,X(N),Y(N) > > > > DO I=1, N > > Y(I)=Y(I)+ALPHA*X(I) > > ENDDO > > RETURN > > END > [...] > > The loop isn't unrolled with -funroll-loops, either. > > Nope. We don't know how to efficiently unroll loops with > non-constant bounds. We don't try unless forced ... Huh? Then there must be something pretty wrong with the alpha port - this is the inner loop I get with g77 -O3 -funroll-loops, using gcc-2.95.1 on Linux/Intel: .L6: fld %st(0) fmull (%edx) faddl (%eax) fstpl (%eax) fld %st(0) fmull 8(%edx) faddl 8(%eax) fstpl 8(%eax) fld %st(0) fmull 16(%edx) faddl 16(%eax) fstpl 16(%eax) fld %st(0) fmull 24(%edx) faddl 24(%eax) addl $32,%edx fstpl 24(%eax) addl $32,%eax addl $-4,%ebx jns .L6 Looks cleanly unrolled four times, to me. What's up, Doc ? -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-9619-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 19:34:58 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4742 invoked by alias); 28 Aug 1999 19:34:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4726 invoked from network); 28 Aug 1999 19:34:52 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 28 Aug 1999 19:34:52 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA20574; Sat, 28 Aug 1999 12:34:51 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id MAA18516; Sat, 28 Aug 1999 12:34:51 -0700 Date: Sat, 28 Aug 1999 12:34:51 -0700 From: Richard Henderson To: Toon Moene Cc: martin.kahlert@provi.de, egcs@egcs.cygnus.com Subject: Re: g77 performance on ALPHA Message-ID: <19990828123451.A8370@cygnus.com> References: <199908281130.NAA00385@keksy.linux.provi.de> <19990828114410.A29542@cygnus.com> <37C837A1.816BDB08@moene.indiv.nluug.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <37C837A1.816BDB08@moene.indiv.nluug.nl>; from Toon Moene on Sat, Aug 28, 1999 at 09:25:21PM +0200 On Sat, Aug 28, 1999 at 09:25:21PM +0200, Toon Moene wrote: > Huh? Then there must be something pretty wrong with the alpha port - > this is the inner loop I get with g77 -O3 -funroll-loops, using > gcc-2.95.1 on Linux/Intel: Doh! That's what I get for not looking close enough. ] Preconditioning: Could not find initial value. ] Unrolling failure: Naive unrolling not being done. I wonder what's up with that... r~ From gcc-return-9620-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 19:44:45 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6212 invoked by alias); 28 Aug 1999 19:44:44 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6196 invoked from network); 28 Aug 1999 19:44:42 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 28 Aug 1999 19:44:42 -0000 Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA20806; Sat, 28 Aug 1999 12:44:42 -0700 (PDT) Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4) id MAA18533; Sat, 28 Aug 1999 12:44:42 -0700 Date: Sat, 28 Aug 1999 12:44:42 -0700 From: Richard Henderson To: Toon Moene Cc: martin.kahlert@provi.de, egcs@egcs.cygnus.com Subject: Re: g77 performance on ALPHA Message-ID: <19990828124442.B8370@cygnus.com> References: <199908281130.NAA00385@keksy.linux.provi.de> <19990828114410.A29542@cygnus.com> <37C837A1.816BDB08@moene.indiv.nluug.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <37C837A1.816BDB08@moene.indiv.nluug.nl>; from Toon Moene on Sat, Aug 28, 1999 at 09:25:21PM +0200 On Sat, Aug 28, 1999 at 09:25:21PM +0200, Toon Moene wrote: > Huh? Then there must be something pretty wrong with the alpha port - > this is the inner loop I get with g77 -O3 -funroll-loops, using > gcc-2.95.1 on Linux/Intel: ] Loop unrolling: Not basic or general induction var. Use -fno-rerun-loop-opt. We're somehow losing iteration information that the unroller needs. r~ From gcc-return-9621-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 20:44:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10739 invoked by alias); 28 Aug 1999 20:44:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10724 invoked from network); 28 Aug 1999 20:43:56 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 28 Aug 1999 20:43:56 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id WAA16227; Sat, 28 Aug 1999 22:42:19 +0200 Message-ID: <37C849AA.E727F5B5@moene.indiv.nluug.nl> Date: Sat, 28 Aug 1999 22:42:18 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: Richard Henderson CC: martin.kahlert@provi.de, egcs@egcs.cygnus.com Subject: Re: g77 performance on ALPHA References: <199908281130.NAA00385@keksy.linux.provi.de> <19990828114410.A29542@cygnus.com> <37C837A1.816BDB08@moene.indiv.nluug.nl> <19990828124442.B8370@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Richard Henderson wrote: > On Sat, Aug 28, 1999 at 09:25:21PM +0200, Toon Moene wrote: > > Huh? Then there must be something pretty wrong with the alpha port - > > this is the inner loop I get with g77 -O3 -funroll-loops, using > > gcc-2.95.1 on Linux/Intel: > ] Loop unrolling: Not basic or general induction var. > Use -fno-rerun-loop-opt. We're somehow losing iteration > information that the unroller needs. [ Assuming this advice is directed at Martin ] Just to be sure: You've found that on the Alpha -fno-rerun-loop-opt gets an unrolled loop when specifying -funroll-loops where on the ix86 it doesn't matter ? Strange .... However, you should realize that rerunning loop optimization is a cop-out I thought up three years ago when giv-finding and -reducing in loop.c was far less sophisticated than it is now [due to your own and Joern's work]. It might simply be counterproductive at these modern times ... HTH, -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-9622-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 21:05:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13209 invoked by alias); 28 Aug 1999 21:05:02 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13186 invoked from network); 28 Aug 1999 21:04:57 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 28 Aug 1999 21:04:57 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id OAA11760; Sat, 28 Aug 1999 14:56:37 -0600 X-Mailer: exmh version 2.0.2 To: Toon Moene cc: Richard Henderson , martin.kahlert@provi.de, egcs@egcs.cygnus.com Subject: Re: g77 performance on ALPHA Reply-To: law@cygnus.com In-reply-to: Your message of Sat, 28 Aug 1999 22:42:18 +0200. <37C849AA.E727F5B5@moene.indiv.nluug.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Aug 1999 14:56:37 -0600 Message-ID: <11757.935873797@upchuck.cygnus.com> From: Jeffrey A Law In message <37C849AA.E727F5B5@moene.indiv.nluug.nl>you write: > However, you should realize that rerunning loop optimization is a > cop-out I thought up three years ago when giv-finding and -reducing in > loop.c was far less sophisticated than it is now [due to your own and > Joern's work]. It might simply be counterproductive at these modern > times ... Last I checked rerunning loops opts was still useful for my "favorite architecture". jeff From gcc-return-9623-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 22:50:39 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26038 invoked by alias); 28 Aug 1999 22:50:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26021 invoked from network); 28 Aug 1999 22:50:29 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 28 Aug 1999 22:50:29 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id 2F5D832CD3; Sun, 29 Aug 1999 00:50:01 +0200 (MEST) Received: from Moufang.suse.de (Moufang.suse.de [10.0.0.7]) by Galois.suse.de (Postfix) with ESMTP id 0505B67BA; Sun, 29 Aug 1999 00:50:01 +0200 (MEST) Received: (from pthomas@localhost) by Moufang.suse.de (8.9.3/8.9.3) id AAA21898; Sun, 29 Aug 1999 00:49:59 +0200 Date: Sun, 29 Aug 1999 00:49:58 +0200 From: Philipp Thomas To: gcc@gcc.gnu.org Cc: "Jeffrey A . Law" , Manfred Hollstein Subject: code changes and i18n dependencies Message-ID: <19990829004958.A11633@Moufang.suse.de> Mail-Followup-To: gcc@gcc.gnu.org, "Jeffrey A . Law" , Manfred Hollstein Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Folks, I just compiled my first CVS gcc after starting in my job. And I discovered that I had to delete two files from the i18n dependency list (gcc/po/POTFILES.in), namely cp/sig.c and gcc/sched.c. So would those of you who change the code in such a way that results in either files getting added or deleted PLEASE update gcc/po/POTFILES.in ? At the moment it's not so much of a problem, as a) NLS is disabled by default and b) only messages for en_UK exist. But I have sent the master catalog file to the maintainer of the FSF i18n project, Francois Pinoir, in the hope that translations start to get rolling in (that is, besides the german one I'm working on). It is my wish to get i18n in such a shape that we can start turning it on by default and I'll start again working on contributing to that effort as soon as I've really settled down. And the moment i18n support becomes a reality, changes like the ones mentioned above will hurt us. On a side note. Jeff and Manfred, I just discovered that the current configury links gcc/intl/libgettext.h to gcc/intl/libintl.h despite the fact that the build system (linux and glibc2.1) has libintl.h in /usr/include and gcc was configured to *not* use the included gettext. This results in link failure because those headers differ in a number of macros. Question now is how to resolve that failure. I solved it temporarily by linking the system libintl.h to gcc/intl but would that also generally be the right solution ? -- Philipp Thomas close the window - the penguin is freezing ------------------------------------------------------------ SuSE GmbH, Tel: +49-911-7405330 Schanzaeckerstr. 10, Fax: +49-911-3206727 90443 Nuernberg, WWW: http://www.suse.de Germany ------------------------------------------------------------ From gcc-return-9624-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 23:48:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31886 invoked by alias); 28 Aug 1999 23:48:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31871 invoked from network); 28 Aug 1999 23:48:54 -0000 Received: from windlord.stanford.edu (171.64.12.23) by egcs.cygnus.com with SMTP; 28 Aug 1999 23:48:54 -0000 Received: (qmail 19002 invoked by uid 50); 28 Aug 1999 23:48:47 -0000 To: Gerald Pfeifer Cc: gcc@gcc.gnu.org Subject: Re: GCC 2.95.x: Major problems on Solaris (was: Lost specific.html FAQEntry) References: From: Russ Allbery In-Reply-To: Gerald Pfeifer's message of "Sat, 28 Aug 1999 12:43:55 +0200 (MET DST)" Date: 28 Aug 1999 16:48:47 -0700 Message-ID: Lines: 15 X-Mailer: Gnus v5.4.66/Emacs 19.34 Gerald Pfeifer writes: > 5. Has someone experiencing these problems already submitted bug reports > to the binutils developers resp. Sun? I haven't, under the assumption that the hint file entry in Perl saying that GNU ld wouldn't work meant that this was a known problem. If people think it would help, I can try it again in a few days and put together a fuller problem report. Perl makes extensive use of dynamically loaded modules, and the symptom that I was seeing was that when all of Perl was linked with GNU ld, it couldn't load the dynamic modules that it had just built. -- Russ Allbery (rra@stanford.edu) From gcc-return-9625-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sat Aug 28 23:59:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 627 invoked by alias); 28 Aug 1999 23:59:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 612 invoked from network); 28 Aug 1999 23:59:01 -0000 Received: from windlord.stanford.edu (171.64.12.23) by egcs.cygnus.com with SMTP; 28 Aug 1999 23:59:01 -0000 Received: (qmail 19024 invoked by uid 50); 28 Aug 1999 23:58:54 -0000 To: Gerald Pfeifer Cc: gcc@gcc.gnu.org Subject: Re: Workaround for Sun V5.0 compiler References: From: Russ Allbery In-Reply-To: Gerald Pfeifer's message of "Sat, 28 Aug 1999 12:51:25 +0200 (MET DST)" Date: 28 Aug 1999 16:58:54 -0700 Message-ID: Lines: 22 X-Mailer: Gnus v5.4.66/Emacs 19.34 Gerald Pfeifer writes: > On Fri, 27 Aug 1999, Jeffrey A Law wrote: >> There's been numerous reports of bootstrap comparison failures when >> building gcc-2.95[.1] with the Sun V5.0 compilers. Through the efforts >> of Patrick Chan we have been able to isolate a bug in the Sun V5.0 >> compiler. Ah, that explains the make compare failure the first time around. > Would you mind adding a note to install/specific.html about Sun V5.0 > compilers being broken? (Resp. a note that GCC 2.95.2 will work around > that bug, if you decide to add that patch to the branch?) I forgot to mention this when I was sending in my report. I got a make compare failure on a single file when bootstrapping with Sun's compiler; I just installed the stage three compiler and then bootstrapped again with that. The result passed make compare; I haven't run it through any hard tests yet, though. -- Russ Allbery (rra@stanford.edu) From gcc-return-9626-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 00:07:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1855 invoked by alias); 29 Aug 1999 00:07:41 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1840 invoked from network); 29 Aug 1999 00:07:40 -0000 Received: from 209-249-66-150.snj0.flashcom.net (HELO ocean.lucon.org) (postfix@209.249.66.150) by egcs.cygnus.com with SMTP; 29 Aug 1999 00:07:40 -0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 7194E8EEE; Sat, 28 Aug 1999 17:06:59 -0700 (PDT) Subject: Re: GCC 2.95.x: Major problems on Solaris (was: Lost specific.html FAQEntry) To: rra@stanford.edu (Russ Allbery) Date: Sat, 28 Aug 1999 17:06:59 -0700 (PDT) Cc: pfeifer@dbai.tuwien.ac.at (Gerald Pfeifer), gcc@gcc.gnu.org In-Reply-To: from "Russ Allbery" at Aug 28, 1999 04:48:47 PM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990829000659.7194E8EEE@ocean.lucon.org> From: hjl@lucon.org (H.J. Lu) > > Gerald Pfeifer writes: > > > 5. Has someone experiencing these problems already submitted bug reports > > to the binutils developers resp. Sun? > > I haven't, under the assumption that the hint file entry in Perl saying > that GNU ld wouldn't work meant that this was a known problem. If people > think it would help, I can try it again in a few days and put together a > fuller problem report. Perl makes extensive use of dynamically loaded > modules, and the symptom that I was seeing was that when all of Perl was > linked with GNU ld, it couldn't load the dynamic modules that it had just > built. > There are known bugs in binutils 2.9.1 on Solaris/Sparc. Quite a few Solaris/Sparc bugs have been fixed in binutils in cvs. -- H.J. Lu (hjl@gnu.org) From gcc-return-9627-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 02:20:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13776 invoked by alias); 29 Aug 1999 02:20:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13761 invoked from network); 29 Aug 1999 02:20:17 -0000 Received: from disaster.jaj.com (HELO jaj.com) (209.64.26.3) by egcs.cygnus.com with SMTP; 29 Aug 1999 02:20:17 -0000 Received: (from pedwards@localhost) by jaj.com (8.7.5/8.7.3) id WAA12572 for gcc@gcc.gnu.org; Sat, 28 Aug 1999 22:24:39 -0400 Date: Sat, 28 Aug 1999 22:24:39 -0400 From: Phil Edwards Message-Id: <199908290224.WAA12572@jaj.com> To: gcc@gcc.gnu.org Subject: Re: GCC 2.95.x: Major problems on Solaris (was: Lost specific.html FAQEntry) > 1. I have already performed a couple of updates to > http://gcc.gnu.org/install/ but it seems we still need some > further ones. > > Patches and hints are most welcome, as are updates to existing stuff. Possibly remind the reader/installer that when installing the 5.0 tools, the "install all the patches" script on that CD (which the CD install instructions assume that you run, of course) adds 107058-01 automatically. I only /happened/ to catch the patch # scrolling by and /happened/ to recall reading the specific.html blurb a month before. I suspect some people can get into problems this way. > 5. Has someone experiencing these problems already submitted bug reports > to the binutils developers resp. Sun? I can submit bugs to Sun (we have a support contract and I have some spare time), but I found out this week that the mailserver at work is on the ORBS blacklist :-( so I've been holding off from joining the discussion until I can actually send mail to these lists. I will be more than willing to help once I convince the mail admin... Phil From gcc-return-9628-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 02:26:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14751 invoked by alias); 29 Aug 1999 02:26:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14736 invoked from network); 29 Aug 1999 02:26:03 -0000 Received: from mail.iglobal.net (209.164.193.7) by egcs.cygnus.com with SMTP; 29 Aug 1999 02:26:03 -0000 Received: from wizard (denm1-26.iglobal.net [207.43.204.56]) by mail.iglobal.net (8.9.3/8.9.3) with SMTP id VAA03528 for ; Sat, 28 Aug 1999 21:26:01 -0500 Message-Id: <3.0.6.32.19990828213129.007a5900@mail.iglobal.net> X-Sender: gressett@mail.iglobal.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Sat, 28 Aug 1999 21:31:29 -0700 To: gcc@gcc.gnu.org From: David Gressett Subject: Successful build of gcc 2.95.1 on SCO OpenServer 5.05 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" built gcc ang g++; did not attempt any other languages config.guess produced i586-pc-sco3.2v5.0.5 From gcc-return-9629-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 09:25:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6981 invoked by alias); 29 Aug 1999 09:25:34 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6728 invoked from network); 29 Aug 1999 09:24:13 -0000 Received: from mail.provi.de (193.98.9.7) by egcs.cygnus.com with SMTP; 29 Aug 1999 09:24:13 -0000 Received: from kahlert.linux.provi.de ([195.222.239.44] helo=keksy.linux.provi.de) by mail.provi.de with esmtp (Exim 2.12 #1) id 11L1C8-0003iU-00; Sun, 29 Aug 1999 11:24:13 +0200 Received: (from martin@localhost) by keksy.linux.provi.de (8.8.8/8.8.8) id LAA00490; Sun, 29 Aug 1999 11:28:02 +0200 Message-ID: <19990829112801.A487@keksy.linux.provi.de> Date: Sun, 29 Aug 1999 11:28:01 +0200 From: Martin Kahlert To: N8TM@aol.com Cc: egcs@egcs.cygnus.com Subject: Re: g77 performance on ALPHA Reply-To: martin.kahlert@provi.de References: <91e2f005.24f95ce8@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <91e2f005.24f95ce8@aol.com>; from N8TM@aol.com on Sat, Aug 28, 1999 at 11:40:24AM -0400 Quoting N8TM@aol.com (N8TM@aol.com): > In a message dated 8/28/99 3:28:13 AM PST, martin.kahlert@provi.de writes: > > > So, how could g77 be improved most easily? > > Is it a problem with the Haifa-scheduler? It seems to me that gcc > > can't take that much advantage from unrolling like Compaq's compiler. > As your code shows, gcc/g77 schedulers, either the old one or Haifa, don't do > much for pipelined processors which lack out-of-order execution or shadow > register re-mapping. They do fairly well on several out-of-order processors. > For example, my g77 code speeded up more with a change from R10000 to R12000 > processor than the MipsPro code did, and I'm getting generally 80% of the > performance from g77 which I get from MipsPro f90 with a great deal of array > syntax optimization. O.k. this rises the dumb question (sorry, i never hacked inside gcc): Why use such a complicate thing like the Haifa scheduler at all when we rely on out of order cpus? Why not just emit instructions as soon as they arise? (Perhaps after a good register allocator) If i imagine correctly, lcc does something like that. > The trend in some of the processor families has been to make use of OOO etc. > to enable fast execution of simple object code. As the gnu compilers are > required to perform well on such processors, including those which have a > small set of registers directly available to the program, I suppose it's > unlikely that good performance will be obtained where such specialized code > generation is needed. The Pentium II processor runs quite well with the > -mpentiumpro option, which is the one which generates code compatible with > processors back to 486, but without skewing scheduling toward the older > models. This is particularly true of code which doesn't spend much time in > tight little loops. Most long running progs will spend a lot of time in quite small loops. But you are perfectly right, gcc-2.95.1 is quite good on PPro machines. I get only about 10% by using a commercial compiler, here. > A trend which goes along with the development of processor families is that > the compilers are tuned for the model which has the largest customer base > paying current support contracts and buying compilers. For example, the > current MipsPro compilers have lost performance on the last Mips models which > lack OOO, even though the architecture switches are retained. g77 never got > even 40% of the speed of the chip vendor's compilers on those older models, > and I'm sure that the vendors weren't thinking of g77 when they developed > better hardware which depends less on code tuning. > > If the resources were available, I would rather see effort spent on compiler > transformations such as outer unrolling than on targeting specific CPU models. I use gcc/g77 because of its wide range of supported architectures. So good code on all architectures is a desireable thing for me, too. Thanks for your long reply, Martin. -- Your mouse has moved, Windows must be restarted for changes to take affect - restart now? From gcc-return-9630-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 10:19:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14966 invoked by alias); 29 Aug 1999 10:19:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14944 invoked from network); 29 Aug 1999 10:17:37 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 29 Aug 1999 10:17:37 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id EAA06732; Sun, 29 Aug 1999 04:08:52 -0600 X-Mailer: exmh version 2.0.2 To: Mark Klein cc: gcc@gcc.gnu.org Subject: Re: HARD_REGNO_MODE_OK on PA-RISC (revisited) Reply-To: law@cygnus.com In-reply-to: Your message of Fri, 27 Aug 1999 17:20:48 PDT. <4.1.19990827171727.00c5a960@garfield.dis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 29 Aug 1999 04:08:51 -0600 Message-ID: <6729.935921331@upchuck.cygnus.com> From: Jeffrey A Law In message <4.1.19990827171727.00c5a960@garfield.dis.com>you write: > OK. I'll keep tracking what you've got (thank heaven I ported CVS to MPE). > Let me know when you want me to repost them and I'll do so. One possibility would be to try to deal with it in smaller hunks rather than all at once. We can start with stuff that is non-controversial then deal with progressively more issues. That way we can work to reduce the amount of patches you have to carry around and we don't have to do a "mega patch" (which have the tendency to break things). So let's start with just your new config files and configure.in fragment first. Can you send just those pieces? > For sake of argument, here's mine. I reformatted it a bit to understand it > better. The only real changes are to handle the long double: A few notes.... > > struct rtx_def * > function_arg(cum, mode, type, named) > const CUMULATIVE_ARGS *cum; > enum machine_mode mode; > tree type; > int named; We always indent function arguments 5 spaces. Not 2, not 4, not a tab, but 5 spaces (hell if I know why the GNU standards mandate 5 spaces). > /* > * See if there is at least one argument register still available. > */ We write comments like /* blah blah foo bar com. */ > if (4 >= cum->words + FUNCTION_ARG_SIZE (mode, type)) > { > > if (!TARGET_PORTABLE_RUNTIME || > type == 0 || > !FLOAT_MODE_P (mode) || > TARGET_SOFT_FLOAT || > cum->nargs_prototype > 0) We write conditionals like if (cond1 || cond2 || cond3) > { > if (FUNCTION_ARG_SIZE (mode, type) > 2) We always indent two spaces after an open-curley. As for the actual code, I suspect it's similar to the stuff we're playing with internally, but simpler :-) The PA64 calling conventions are similar, but not quite the same as the portable runtime. Ugh. It certainly is a hell of a lot easier to follow the code once it's broken out into a function :-) Probably the next one to break into a function on the PA will be GO_IF_LEGITIMATE_ADDRESS. The whole idea that we have macros that take up a page is absurd. Nobody should write code like that :-) jeff From gcc-return-9631-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 10:59:07 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19779 invoked by alias); 29 Aug 1999 10:59:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19726 invoked from network); 29 Aug 1999 10:57:37 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 29 Aug 1999 10:57:37 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id MAA03869; Sun, 29 Aug 1999 12:54:51 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id MAA00592; Sun, 29 Aug 1999 12:51:22 +0200 Date: Sun, 29 Aug 1999 12:51:22 +0200 Message-Id: <199908291051.MAA00592@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: oliva@dcc.unicamp.br CC: cj@interlog.com, d92-foh@nada.kth.se, gcc@gcc.gnu.org In-reply-to: (message from Alexandre Oliva on 25 Aug 1999 10:02:45 -0300) Subject: Re: Strange behaviour in C++... References: <3.0.32.19990825075547.009b3930@mail.interlog.com> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > In fact, I seem to recall there was an attempt to fix it for gcc 2.95 > (was it Martin v. Löewis?), but, if it ever got in the CVS tree, it > seems that it didn't work for this case :-( It's not in the tree, yet. The most recent version of the patch is http://egcs.cygnus.com/ml/gcc-patches/1999-05/msg00012.html with Jason's comments in http://egcs.cygnus.com/ml/gcc-patches/1999-06/msg00220.html It didn't get into 2.95 (as I hoped), and because of Jason's objections, it didn't go into the mainline, either. Also remember that the fix introduces a binary incompatibility; so you'd need to use a command line option to activate it, anyway. In the light of the ia64 abi, justification for such a patch might have changed - although you'll need vtable lists in that ABI, as well, so the effort is not completely wasted. Regards, Martin From gcc-return-9632-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 11:03:38 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21094 invoked by alias); 29 Aug 1999 11:03:37 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20833 invoked from network); 29 Aug 1999 11:02:15 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 29 Aug 1999 11:02:15 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id MAA04021; Sun, 29 Aug 1999 12:59:51 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id MAA00607; Sun, 29 Aug 1999 12:55:55 +0200 Date: Sun, 29 Aug 1999 12:55:55 +0200 Message-Id: <199908291055.MAA00607@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: cgriffin@bbn.com CC: gcc@gcc.gnu.org In-reply-to: Subject: Re: Tools for GCC 2.95.1 References: User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > I'm looking for someone who can tell me what tools (binutils & gdb) > I should be able to use with gcc 2.95.1 . We are using RedHat 6, so > would I need to build the most recent gdb, or is it going to work > to use the gdb which comes on the system? Both binutils and gdb that come with your system should work fine. Regards, Martin From gcc-return-9633-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 11:37:54 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24505 invoked by alias); 29 Aug 1999 11:37:43 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24457 invoked from network); 29 Aug 1999 11:36:16 -0000 Received: from 12-204.015.popsite.net (HELO tandbserver) (198.79.106.204) by egcs.cygnus.com with SMTP; 29 Aug 1999 11:36:16 -0000 From: T & B Associates To: Message-Id: <419.436401.19197153macbob@mailcity.com> Subject: REPAIR YOUR CREDIT Award winning book & CD ROM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit //REMOVAL INSTRUCTIONS BELOW// The inspiration for this book and CD ROM comes after more than 10 years of helping friends, family, and eventually thousands of consumers, with the tribulations of trying to resolve personal credit problems. The essence of this book is derived from the fact that the author is not an attorney nor an advocate for the practices of the credit bureaus. Instead, a consumer who has experienced and overcome the frustrating, solemn depths of bad credit. I have shared my experiences and techniques with thousands of others, who in return shared what worked best. I then refined and documented which techniques were most effective. While struggling to free myself from what seemed to be an eternity of stress and insurmountable problems, I discovered that one can easily use the very same laws that were hindering you, to actually help you. You may ask, is this really legal? Sure, if you don't get caught. I am only joking, it is very legal and very possible. Experian states, "you should dispute all information you feel is not adequately representative of what you believe to be true." Bad information on your credit report not only effects you, but businesses who want to offer you credit, everybody loses. Therefore, challenge everything that's questionable and let the credit bureaus prove its accuracy. How many times have you been pulled over for speeding and told by the cop, "by the way, if I don't show up for court, this ticket and fine will be dismissed." The consumer can use this same principle to resolve their own credit problems. The following pages contain only the most efficient, proven effective, Step-By-Step instructions on how to resolve derogatory information on your credit reports, dealing with creditors and collectors, debt reduction and rebuilding credit, and Bankruptcy. If you want to read 100+ pages of legal jargon outlining the credit laws, this book is NOT for you. NO PREACHING, JUST TEACHING!!! YOU GETTHE BOOK & the CD ROM with step by instructions all for the the amazingly low price of $39.95 + shipping & handling $4.05 = $$44.00 Total ORDER NOW... Send Cash, Check or Money Order to address below or print this form and fax Credit Card Info. See form below. Be sure to include: NAME, ADDRESS, CITY, ST, ZIP and please include your email address in case we need to contact you. NOTE: Packages inferior to this one are selling for over $295.00 You may also call in your order to 800 483-0094 pin/ext 494-2228# $39.95 + shipping & handling $4.05 = $$44.00 Total Make check or M.O. payable to: ~~~~~~~~~~~~~~~~~~~~ T & B Associates 112 Harvard Avenue, Suite 84 Claremont, CA 91711 909 605-6233 - - - - - - - - - - - Credit Card Form - - - - - - - - - - - - - - - - - NAME:_________________________________ ADDRESS:_________________________ CITY/ST/ZIP_________________________ TYPE OF CARD (m/c,visa,discover)_________ EXP DATE (MM/YY)____________ TELEPHONE ( ) ____ ________ EMAIL ADDRESS ____________________________ Print and FAX to (419) 715-9641 (ORDERS ONLY) //REMOVAL INSTRUCTIONS// To be removed from this list FAX your printed or typed email address to 419 715- 9641. Removal requests sent OR phoned to any other number are not able to be processed. From gcc-return-9634-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 13:57:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28136 invoked by alias); 29 Aug 1999 13:57:21 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28086 invoked from network); 29 Aug 1999 13:55:59 -0000 Received: from roma.axis.se (193.13.178.2) by egcs.cygnus.com with SMTP; 29 Aug 1999 13:55:59 -0000 Received: from ignucius.axis.se (hp@ignucius.axis.se [171.16.1.218]) by roma.axis.se (8.9.3/8.9.3) with ESMTP id PAA07753; Sun, 29 Aug 1999 15:55:57 +0200 (MEST) Received: (from hp@localhost) by ignucius.axis.se (8.9.3/8.9.3/Debian/GNU) id PAA17048; Sun, 29 Aug 1999 15:55:57 +0200 Date: Sun, 29 Aug 1999 15:55:57 +0200 Message-Id: <199908291355.PAA17048@ignucius.axis.se> From: Hans-Peter Nilsson To: pfeifer@dbai.tuwien.ac.at CC: gcc@gcc.gnu.org In-reply-to: Subject: Re: GCC 2.95.x: Major problems on Solaris (was: Lost specific.html FAQ Entry) On Sat, 28 Aug 1999, Gerald Pfeifer wrote: > Folks, we have had an incredible number of problem reports concerning > Solaris (mostly Solaris 7, binutils vs vendor tools, Sun make vs gmake...) > for 2.95.x. > 4. Perhaps there are GNU make specific features in some of our Makefiles? > I vaguely remember some portability(?) patches several months ago, > which were supposed to allow for srcdir != objdir builds with Sun make. Most of those patches made it into the source. I made a (hopefully vague) promise at that time about making a patch for the egcstensions page. I've finally fulfilled that and made one that people can apply to the gcc-2.95.1 release (only). Please refer to . If nobody does it sooner (preferably), I'll send patches for egcstensions.html and install/specific.html. Note that it seems I failed to foil the archive engine into *not* archiving the patch as a separate attachment, to avoid "patch" complications. So I also put it at . If you prefer, feel free to put it at gcc.gnu.org. brgds, H-P From gcc-return-9635-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 15:49:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8365 invoked by alias); 29 Aug 1999 15:49:31 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7087 invoked from network); 29 Aug 1999 15:48:08 -0000 Received: from adsl-206-170-148-33.dsl.snfc21.pacbell.net (206.170.148.33) by egcs.cygnus.com with SMTP; 29 Aug 1999 15:48:08 -0000 Received: from localhost (localhost [127.0.0.1]) by adsl-206-170-148-33.dsl.snfc21.pacbell.net (8.9.3/8.9.3) with ESMTP id IAA05089; Sun, 29 Aug 1999 08:51:56 -0700 To: martin@mira.isdn.cs.tu-berlin.de Cc: oliva@dcc.unicamp.br, cj@interlog.com, d92-foh@nada.kth.se, gcc@gcc.gnu.org Subject: Re: Strange behaviour in C++... In-Reply-To: <199908291051.MAA00592@mira.isdn.cs.tu-berlin.de> References: <3.0.32.19990825075547.009b3930@mail.interlog.com> <199908291051.MAA00592@mira.isdn.cs.tu-berlin.de> X-Mailer: Mew version 1.94b25 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.codesourcery.com Organization: CodeSourcery, LLC From: Mark Mitchell Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990829085155P.mitchell@codesourcery.com> Date: Sun, 29 Aug 1999 08:51:55 -0700 X-Dispatcher: imput version 990425(IM115) Lines: 24 >>>>> "Martin" == Martin v Loewis writes: Martin> It didn't get into 2.95 (as I hoped), and because of Martin> Jason's objections, it didn't go into the mainline, I, for one, think we should really try to get this patch into 3.0. I thought that you had some schemes for backwards-compatibility that would allow us to reap the benefits of the patch without breaking the ABI. In any case, this is an important bug, and we should fix it. You've done most of the work; we should get this finished up and checked in. Unfortunately, I don't have time to look at this for several weeks, but maybe I can at that point. I don't know if Jason has time to look, or whether he agrees with me that it's important. (Another consistent point of view would be to just wait for the IA-64 ABI to settle out, and implement that as the new ABI. I'm just doubtful that will happen before the next major release.) -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From gcc-return-9636-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 16:04:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10594 invoked by alias); 29 Aug 1999 16:04:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10300 invoked from network); 29 Aug 1999 16:03:34 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 29 Aug 1999 16:03:34 -0000 Received: from saturn.hollstein.net (rtl.cygnus.com [205.180.230.21]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA22206; Sun, 29 Aug 1999 09:03:29 -0700 (PDT) Received: (from manfred@localhost) by saturn.hollstein.net (8.9.3/8.9.3) id RAA23450; Sun, 29 Aug 1999 17:27:21 +0200 Date: Sun, 29 Aug 1999 17:27:18 +0200 (MEST) From: Manfred Hollstein To: pthomas@suse.de Cc: gcc@gcc.gnu.org, law@cygnus.com Subject: Re: code changes and i18n dependencies In-Reply-To: <19990829004958.A11633@Moufang.suse.de> References: <19990829004958.A11633@Moufang.suse.de> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14281.20449.911081.771040@saturn.hollstein.net> Reply-To: Manfred Hollstein Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII On Sun, 29 August 1999, 00:49:58, pthomas@suse.de wrote: > Folks, > I just compiled my first CVS gcc after starting in my job. And I discovered > that I had to delete two files from the i18n dependency list > (gcc/po/POTFILES.in), namely cp/sig.c and gcc/sched.c. I just installed a fix for this. > > So would those of you who change the code in such a way that results in either > files getting added or deleted PLEASE update gcc/po/POTFILES.in ? > > At the moment it's not so much of a problem, as a) NLS is disabled by > default and b) only messages for en_UK exist. > > But I have sent the master catalog file to the maintainer of the FSF i18n > project, Francois Pinoir, in the hope that translations start to get rolling > in (that is, besides the german one I'm working on). > > It is my wish to get i18n in such a shape that we can start turning it on by > default and I'll start again working on contributing to that effort as soon > as I've really settled down. > > And the moment i18n support becomes a reality, changes like the ones > mentioned above will hurt us. > > On a side note. Jeff and Manfred, I just discovered that the current configury > links gcc/intl/libgettext.h to gcc/intl/libintl.h despite the fact that the > build system (linux and glibc2.1) has libintl.h in /usr/include and gcc was > configured to *not* use the included gettext. This results in link failure > because those headers differ in a number of macros. > > Question now is how to resolve that failure. I solved it temporarily by > linking the system libintl.h to gcc/intl but would that also generally be the > right solution ? Could you please describe, (a) how you configured your tree, and (b) what OS you are using? I just tried this on Red Hat Linux 6.0: $ env CC=gcc 'CFLAGS=-O2 -g' 'CXXFLAGS=-O2 -g' LDFLAGS= 'LINGUAS=de es fr it' \ 'INSTALL=/usr/bin/install -c' 'INSTALL_DATA=/usr/bin/install -c -m 644' \ 'INSTALL_PROGRAM=/usr/bin/install -c -m 755' \ /bin/sh ../egcs-19990829/configure i586-redhat6-linux-gnu --srcdir=../egcs-19990829 \ --prefix=/opt/gnu --with-gnu-as --with-gnu-ld --enable-shared \ --enable-version-specific-runtime-libs --enable-java-gc=boehm \ --enable-fast-character --enable-threads=posix --with-local-prefix=/opt/gnu \ --enable-nls --verbose ... checking whether NLS is requested... yes checking whether included gettext is requested... no checking for libintl.h... yes checking for gettext in libc... yes ... checking whether included gettext is requested... no checking for libintl.h... (cached) yes checking for gettext in libc... (cached) yes AND there is NO link in gcc/intl. Perhaps, gettext is not properly installed on your system. > > > -- > Philipp Thomas > > close the window - the penguin is freezing > > > ------------------------------------------------------------ > SuSE GmbH, Tel: +49-911-7405330 > Schanzaeckerstr. 10, Fax: +49-911-3206727 > 90443 Nuernberg, WWW: http://www.suse.de > Germany > ------------------------------------------------------------ > l8er, manfred From gcc-return-9637-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 16:04:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 10644 invoked by alias); 29 Aug 1999 16:04:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 10310 invoked from network); 29 Aug 1999 16:03:36 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 29 Aug 1999 16:03:36 -0000 Received: from saturn.hollstein.net (rtl.cygnus.com [205.180.230.21]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA22203; Sun, 29 Aug 1999 09:03:23 -0700 (PDT) Received: (from manfred@localhost) by saturn.hollstein.net (8.9.3/8.9.3) id SAA02872; Sun, 29 Aug 1999 18:01:11 +0200 Date: Sun, 29 Aug 1999 18:01:11 +0200 (MEST) From: Manfred Hollstein To: gaius@glam.ac.uk Cc: mrs@wrs.com, gcc@gcc.gnu.org Subject: Re: [gaius@glam.ac.uk: GNU Modula-2 progress] In-Reply-To: References: <199908252358.QAA03876@kankakee.wrs.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14281.22788.469986.425468@saturn.hollstein.net> Reply-To: Manfred Hollstein Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Hi Gaius, On Thu, 26 August 1999, 14:31, gaius@glam.ac.uk wrote: > > > > rms wanted us to get in touch with you so we can coordinate getting > > the work you've been doing into the compiler. > > Many thanks for the hints on how to integrate Modula-2 changes into > gcc - especially the URL and cvs info. Cool, that's great news indeed! I enjoyed learning Modula-2 several years ago (pooh, is it really that long ago? ...), but I'm still a big fan of Modula-2, and - believe it or not - during the last few weeks I thought about writing an M2 frontend to be integrated into gcc myself... ;-) If you need any help, don't hesitate and ask for it. l8er, manfred > > Here is part of the message I've just sent to rms about who wrote m2f: > > > Thanks for the reply, for my sins I wrote all the compiler modules > and all the library modules expect two (see below). It is a > fully functioning Modula-2 compiler which currently runs on Linux and > generates 80[3456]86 code, 8086 and is32 (a research abstract machine > processor). It generated GDB .stabs info and worked well with the > emacs/gdb combination. On the plus side it allows declarations in any > order - as per Wirth's definition and it also allows abstract types to > be any type, not just a pointer type. It conforms to Programming in > Modula-2 edition 2 by N. Wirth (albeit the library modules are different). > > On the downside the code generator of m2f could be improved. > Thus one of the many attractions of linking the front end of > m2f up to the gcc back end :-). > > There are two library modules which I didn't write and I shall rewrite > these modules (or remove them) Sort.mod (quicksort and bubble sort - > actually the compiler doesn't need these so it might be easier to rm it). > Also FIO.mod the file system input output module, which to keep things > clean I'll take it out and write an alterative module blind following the > guidelines in the emacs info system (using dynamic memory and different > algorithms/approaches). Currently the all the library modules are not held > by GPL but after this work they could be under GPL if you wish? I'm very > keen for as much to be under GPL as possible. > > Any advice? > > Is this the right thing to do? I've signed a GNU registration form > 3 years ago when I submitted some changes to gdb and binutils. Do > I need to sign another for m2f/gcc ? > > cheers Gaius > > URL: http://floppsie.comp.glam.ac.uk click on Modula-2 and m2f under > "Scratching an itch" From gcc-return-9638-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 16:32:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12928 invoked by alias); 29 Aug 1999 16:32: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12913 invoked from network); 29 Aug 1999 16:32:47 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 29 Aug 1999 16:32:47 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id SAA24329; Sun, 29 Aug 1999 18:29:50 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id SAA01748; Sun, 29 Aug 1999 18:28:08 +0200 Date: Sun, 29 Aug 1999 18:28:08 +0200 Message-Id: <199908291628.SAA01748@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: mark@codesourcery.com CC: oliva@dcc.unicamp.br, cj@interlog.com, d92-foh@nada.kth.se, gcc@gcc.gnu.org In-reply-to: <19990829085155P.mitchell@codesourcery.com> (message from Mark Mitchell on Sun, 29 Aug 1999 08:51:55 -0700) Subject: Re: Strange behaviour in C++... References: <3.0.32.19990825075547.009b3930@mail.interlog.com> <199908291051.MAA00592@mira.isdn.cs.tu-berlin.de> <19990829085155P.mitchell@codesourcery.com> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > I, for one, think we should really try to get this patch into 3.0. I > thought that you had some schemes for backwards-compatibility that > would allow us to reap the benefits of the patch without breaking the > ABI. > > In any case, this is an important bug, and we should fix it. You've > done most of the work; we should get this finished up and checked in. Thanks for the encouragement. The backwards-compatibility part of the approach is not implemented yet. I hope I can complete that in the near future. Regards, Martin From gcc-return-9639-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 16:35:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13807 invoked by alias); 29 Aug 1999 16:35:15 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13792 invoked from network); 29 Aug 1999 16:35:13 -0000 Received: from imo27.mx.aol.com (198.81.17.71) by egcs.cygnus.com with SMTP; 29 Aug 1999 16:35:13 -0000 Received: from N8TM@aol.com by imo27.mx.aol.com (mail_out_v22.4.) id eOKUa01400 (7819); Sun, 29 Aug 1999 12:33:40 -0400 (EDT) From: N8TM@aol.com Message-ID: <210763a1.24fabae3@aol.com> Date: Sun, 29 Aug 1999 12:33:39 EDT Subject: Re: g77 performance on ALPHA To: martin.kahlert@provi.de CC: egcs@egcs.cygnus.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows sub 15 In a message dated 8/29/99 1:24:27 AM PST, martin.kahlert@provi.de writes: > Why use such a complicate thing like the Haifa scheduler at all when > we rely on out of order cpus? > Why not just emit instructions as soon as they arise? (Perhaps after > a good register allocator) I'll give the dumb user's response, since there are people on the list much better able to give the expert response. Even with out-of-order execution, there appears to be a clear advantage to initiating instructions in the most effective order. Whether this is associated with the limited length of out-of-order queues, with the possibility of exhausting the supply of shadow registers, or additional processing time spend shuffling instructions in the queues, or even with cacheing considerations, or likely some combination of the above, I'm not able to say. I do think that I have seen evidence that some processors absorb additional time when shuffling memory read and write operations. A relevant comparison here might be between the g77 -mpentiumpro and -march=pentiumpro, in those situations where scheduling is different although the instructions chosen are the same. There are cases with -mpentiumpro where one operand is accessed several instructions earlier than the other, while -march=pentiumpro accesses both operands several instructions before use, increasing the depth of use of the stack. Sometimes, this clearly avoids a stall wait for the second operand. >>I use gcc/g77 because of its wide range of supported architectures. >>So good code on all architectures is a desireable thing for me, too. I agree. >>Thanks for your long reply, >>Martin. I'm trying not to be so long. Tim From gcc-return-9640-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 17:00:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17004 invoked by alias); 29 Aug 1999 17:00:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16985 invoked from network); 29 Aug 1999 17:00:23 -0000 Received: from mobil.surnet.ru (root@195.54.2.7) by egcs.cygnus.com with SMTP; 29 Aug 1999 17:00:23 -0000 Received: (from uucgilh@localhost) by mobil.surnet.ru (8.9.1a/8.9.1) with UUCP id WAA02045 for gcc@gcc.gnu.org; Sun, 29 Aug 1999 22:56:20 +0600 (UDT) Received: (from uucp@localhost) by cgilh.chel.su (8.8.7/8.8.7) with UUCP id WAA03645 for gcc@gcc.gnu.org; Sun, 29 Aug 1999 22:34:13 +0600 Received: from localhost (ilia@localhost) by localhost.cgu.chel.su (8.9.2/8.9.2) with ESMTP id WAA00505 for ; Sun, 29 Aug 1999 22:34:25 +0600 (ESS) (envelope-from ilia@cgilh.chel.su) X-Authentication-Warning: localhost.cgu.chel.su: ilia owned process doing -bs Date: Sun, 29 Aug 1999 22:34:24 +0600 (ESS) From: Ilia Chipitsine X-Sender: ilia@localhost.cgu.chel.su To: gcc@gcc.gnu.org Subject: Visual GCC ?! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: 8BIT Hello, everybody. I'd like to hear your opinions about different IDEs which are "front-end"s for GCC. Particularly, I'm interested in one which provides "context-help", I'd like to be able to press Ctrl-F1 keywords :-) Also, I'm sort of interested in visual programming (do not blame me), so I'd collect your thoughts on that subject also. Regards, (îÁÉÌÕÞÛÉÅ ÐÏÖÅÌÁÎÉÑ) Ilia Chipitsine (éÌØÑ ûÉÐÉÃÉÎ) From gcc-return-9641-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 17:33:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19650 invoked by alias); 29 Aug 1999 17:33:05 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19630 invoked from network); 29 Aug 1999 17:32:59 -0000 Received: from postal.thewrittenword.com (china@208.150.51.101) by egcs.cygnus.com with SMTP; 29 Aug 1999 17:32:59 -0000 Received: (from china@localhost) by postal.thewrittenword.com (8.9.3/8.9.3) id MAA09891; Sun, 29 Aug 1999 12:28:17 -0500 (CDT) Date: Sun, 29 Aug 1999 12:28:17 -0500 From: egcs@thewrittenword.com To: Russ Allbery Cc: Dimitri Papadopoulos , egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status Message-ID: <19990829122817.B32502@postal.thewrittenword.com> Reply-To: egcs@egcs.cygnus.com References: <199908271616.SAA08162@orcanie.shfj.cea.fr> <37C71AB3.BEAAA35A@club-internet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Russ Allbery on Fri, Aug 27, 1999 at 04:29:30PM -0700 On Fri, Aug 27, 1999 at 04:29:30PM -0700, Russ Allbery wrote: > Dimitri Papadopoulos writes: > > > In fact, I have built GCC with GNU as/ld (bootstraping with EGCS using > > itself GNU as/ld and putting GNU as/ld in my PATH and /usr/ccs/bin out > > of my PATH). I do have 107058-01 installed but this should have no > > incidence using such a configuration. > > I'd double-check your assumption with gcc -print-search-dirs; remember > that gcc has an internal list of directories that are searched *before* > the user's path is, and on Solaris by default that list contains > /usr/ccs/bin. So it's entirely possible for gcc on Solaris to pick up > vendor as even if it's nowhere in your path. > > I realize that you're not having problems in the same place that I was, > but you're reporting "impossible" random crashes, which is precisely the > symptoms of the problem created by patch 107058-01 at least in my > experience. After we complied egcs 1.1.2, I installed patch 107058-01 and then compiled zlib. Prior to this patch, the compile succeeded and the test program worked fine. After applying the patch, we received SEGV during the test program. I'd recommend staying away from 107058 too. > Russ Allbery (rra@stanford.edu) -- albert chin (china@thewrittenword.com) From gcc-return-9642-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 18:03:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23855 invoked by alias); 29 Aug 1999 18:03:40 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23820 invoked from network); 29 Aug 1999 18:03:36 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 29 Aug 1999 18:03:36 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id 2C62D32D6E; Sun, 29 Aug 1999 20:03:09 +0200 (MEST) Received: from Moufang.suse.de (Moufang.suse.de [10.0.0.7]) by Galois.suse.de (Postfix) with ESMTP id 9B6E967AF; Sun, 29 Aug 1999 20:03:08 +0200 (MEST) Received: (from pthomas@localhost) by Moufang.suse.de (8.9.3/8.9.3) id UAA01232; Sun, 29 Aug 1999 20:03:07 +0200 Date: Sun, 29 Aug 1999 20:03:07 +0200 From: Philipp Thomas To: Manfred Hollstein Cc: gcc@gcc.gnu.org Subject: Re: code changes and i18n dependencies Message-ID: <19990829200307.B1202@Moufang.suse.de> Mail-Followup-To: Manfred Hollstein , gcc@gcc.gnu.org References: <19990829004958.A11633@Moufang.suse.de> <14281.20449.911081.771040@saturn.hollstein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <14281.20449.911081.771040@saturn.hollstein.net>; from Manfred Hollstein on Sun, Aug 29, 1999 at 05:27:18PM +0200 * Manfred Hollstein (mhollstein@cygnus.com) [19990829 18:05]: Hi Manfred, > Could you please describe, > > (a) how you configured your tree, and > (b) what OS you are using? > I can't reproduce it, mostly because I didn't save the original configure call. After deleting my build tree and reconfiguring again the error vanished. But I'll keep an eye open as I might retrigger it. BTW, feels good to be back among the crowd :-))) -- Philipp Thomas close the window - the penguin is freezing ------------------------------------------------------------ SuSE GmbH, Tel: +49-911-7405330 Schanzaeckerstr. 10, Fax: +49-911-3206727 90443 Nuernberg, WWW: http://www.suse.de Germany ------------------------------------------------------------ From gcc-return-9643-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 18:22:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26737 invoked by alias); 29 Aug 1999 18:22:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26696 invoked from network); 29 Aug 1999 18:22:46 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 29 Aug 1999 18:22:46 -0000 Received: from yorick.cygnus.com (yorick.cygnus.com [205.180.230.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA26185; Sun, 29 Aug 1999 11:22:22 -0700 (PDT) Received: (jason@localhost) by yorick.cygnus.com (8.8.7/8.6.4) id LAA05128; Sun, 29 Aug 1999 11:22:22 -0700 To: "Martin v. Loewis" Cc: mark@codesourcery.com, oliva@dcc.unicamp.br, cj@interlog.com, d92-foh@nada.kth.se, gcc@gcc.gnu.org Subject: Re: Strange behaviour in C++... References: <3.0.32.19990825075547.009b3930@mail.interlog.com> <199908291051.MAA00592@mira.isdn.cs.tu-berlin.de> <19990829085155P.mitchell@codesourcery.com> <199908291628.SAA01748@mira.isdn.cs.tu-berlin.de> From: Jason Merrill Date: 29 Aug 1999 11:22:22 -0700 In-Reply-To: "Martin v. Loewis"'s message of "Sun, 29 Aug 1999 18:28:08 +0200" Message-ID: Lines: 18 X-Mailer: Gnus v5.6.45/Emacs 20.3 >>>>> Martin v Loewis writes: >> I, for one, think we should really try to get this patch into 3.0. I >> thought that you had some schemes for backwards-compatibility that >> would allow us to reap the benefits of the patch without breaking the >> ABI. >> >> In any case, this is an important bug, and we should fix it. You've >> done most of the work; we should get this finished up and checked in. > Thanks for the encouragement. The backwards-compatibility part of the > approach is not implemented yet. I hope I can complete that in the > near future. I agree that it should get in for 3.0. Sorry I haven't followed up in a while. Jason From gcc-return-9644-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 18:52:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30735 invoked by alias); 29 Aug 1999 18:52:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30720 invoked from network); 29 Aug 1999 18:52:02 -0000 Received: from grande.dcc.unicamp.br (143.106.1.11) by egcs.cygnus.com with SMTP; 29 Aug 1999 18:52:02 -0000 Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11]) by grande.dcc.unicamp.br (8.9.1/8.9.1) with ESMTP id PAA07286; Sun, 29 Aug 1999 15:51:47 -0300 (EST) Received: from cupuacu.lsd.dcc.unicamp.br.dcc.unicamp.br (oliva@cupuacu.lsd.dcc.unicamp.br [143.106.24.145]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id PAA19784; Sun, 29 Aug 1999 15:51:45 -0300 (EST) To: "Christopher W. Fisher" Cc: gcc@gcc.gnu.org, bug-gcc@gnu.org Subject: Re: error compiling gcc-2.95 1990728 with gnat 3.11p References: From: Alexandre Oliva Date: 29 Aug 1999 15:51:46 -0300 In-Reply-To: "Christopher W. Fisher"'s message of "Sun, 29 Aug 1999 09:46:31 -0400 (EDT)" Message-ID: Lines: 15 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 29, 1999, "Christopher W. Fisher" wrote: > here is the error output I have received when attempting to build > gcc-2.95.1 and gnat. Are you sure this release of gnat supports gcc 2.95.1. Maybe it doesn't, I don't know. Or it might be that you have to build with `make bootstrap', as recommended in the gcc installation instructions, in case that's not what you did. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them From gcc-return-9645-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 19:19:35 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4048 invoked by alias); 29 Aug 1999 19:19:30 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3976 invoked from network); 29 Aug 1999 19:19:26 -0000 Received: from vlsi1.ultra.nyu.edu (128.122.140.213) by egcs.cygnus.com with SMTP; 29 Aug 1999 19:19:26 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA10957; Sun, 29 Aug 99 15:26:09 EDT Date: Sun, 29 Aug 99 15:26:09 EDT From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <9908291926.AA10957@vlsi1.ultra.nyu.edu> To: oliva@dcc.unicamp.br Subject: Re: error compiling gcc-2.95 1990728 with gnat 3.11p Cc: bug-gcc@gnu.org, gcc@gcc.gnu.org Are you sure this release of gnat supports gcc 2.95.1. It most certainly *does not*! The current release of GNAT is based on GCC 2.8.1 and a later release of GNAT will be based on GCC 3.0. There will not be a version of GNAT based on GCC 2.95 because it does not contain fixes needed for GNAT and no testing has been done with GNAT built from those sources. From gcc-return-9646-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 20:52:06 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16255 invoked by alias); 29 Aug 1999 20:52:05 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16238 invoked from network); 29 Aug 1999 20:52:03 -0000 Received: from front1.grolier.fr (194.158.96.51) by egcs.cygnus.com with SMTP; 29 Aug 1999 20:52:03 -0000 Received: from dimitri.localdomain (ppp-172-142.villette.club-internet.fr [195.36.172.142]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA12084 for ; Sun, 29 Aug 1999 22:51:56 +0200 (MET DST) Received: from club-internet.fr (dimitri.localdomain [127.0.0.1]) by dimitri.localdomain (8.8.7/8.8.7/Dimitri) with ESMTP id WAA00766 for ; Sun, 29 Aug 1999 22:46:13 +0200 Message-ID: <37C99C15.BA761E40@club-internet.fr> Date: Sun, 29 Aug 1999 22:46:13 +0200 From: Dimitri Papadopoulos X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: egcs@egcs.cygnus.com Subject: Re: egcs/Solaris status References: <199908271616.SAA08162@orcanie.shfj.cea.fr> <37C71AB3.BEAAA35A@club-internet.fr> <19990829122817.B32502@postal.thewrittenword.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit egcs@thewrittenword.com wrote: > > On Fri, Aug 27, 1999 at 04:29:30PM -0700, Russ Allbery wrote: > > Dimitri Papadopoulos writes: > > > > > In fact, I have built GCC with GNU as/ld (bootstraping with EGCS using > > > itself GNU as/ld and putting GNU as/ld in my PATH and /usr/ccs/bin out > > > of my PATH). I do have 107058-01 installed but this should have no > > > incidence using such a configuration. > > > > I'd double-check your assumption with gcc -print-search-dirs; remember > > that gcc has an internal list of directories that are searched *before* > > the user's path is, and on Solaris by default that list contains > > /usr/ccs/bin. So it's entirely possible for gcc on Solaris to pick up > > vendor as even if it's nowhere in your path. > > > > I realize that you're not having problems in the same place that I was, > > but you're reporting "impossible" random crashes, which is precisely the > > symptoms of the problem created by patch 107058-01 at least in my > > experience. > > After we complied egcs 1.1.2, I installed patch 107058-01 and then > compiled zlib. Prior to this patch, the compile succeeded and the test > program worked fine. After applying the patch, we received SEGV during > the test program. I'd recommend staying away from 107058 too. You are using Sun as/ld. This is why you have problems with patch 107058-01. We are using GNU as/ld, so this patch has no incidence on GCC. In any case, I wouldn't have problems in the situation you are describing. This patch has no incidence on our GCC compiler. The patch updates /usr/ccs/bin/as and our GCC compiler does not use /usr/ccs/bin/as. See the FAQ for details on how this is achieved. From gcc-return-9647-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 21:34:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22250 invoked by alias); 29 Aug 1999 21:34:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22220 invoked from network); 29 Aug 1999 21:34:41 -0000 Received: from aphrodite.is.nl (194.235.232.13) by egcs.cygnus.com with SMTP; 29 Aug 1999 21:34:40 -0000 Received: from kochsalz.com (radio101.demon.nl [212.238.127.120]) by aphrodite.is.nl (2.6 Build 1 (Berkeley 8.8.6)/8.8.4) with SMTP id XAA09358; Sun, 29 Aug 1999 23:36:38 +0200 Message-Id: <199908292136.XAA09358@aphrodite.is.nl> Date: BirdSpam! Yeeaaahhh.....Its from the SpamBird (R) From: Surfing@Bird.DDR.is.nl Reply-To: Surfing@Bird.DDR.is.nl To: Surfing@Bird.DDR.is.nl Subject: Zweitpass,Fuehrerschein,EMail-Adressen,Massenmailprogramme! Benötigen Sie einen Zweitpass und/oder einen neuen Führerschein? Wählen Sie: http://lokomotive.webjump.com NEU: Holen Sie sich selbst immer aktuelle EMail-Adressen aus dem Internet! Länder und Themen FREI WÄHLBAR! Sie brauchen alle Lokomotivführerhäuschenputzergewerkschaften in Deutschland oder vielleicht nur mal schnell alle EMail-Adressen von Telefonläden in DE, AT und NL ?? Unser ADD-ON zum Enterprise-Paket findet auch die exotischten E-Adressen zu tausenden in kurzer Zeit! Moechten Sie Waren oder Dienstleistungen im Internet verkaufen? Betreiben Sie einen Versandhandel? Benoetigen Sie preiswerte Massenwerbung die Sie nur einmal bezahlen aber immer wieder so oft Sie wollen benutzen können? Unser DM 250.- Top-Angebot! (Ideal für Einsteiger!) Holen Sie sich Ihre eigene Software zum Rundmailversand! Dieses Enterprise-Paket enthält eine komplette Software zum Massenmailversand (Läuft auf Win95, Win98 und 3.x) und dazu noch eine Datei mit EINHUNDERTTAUSEND aktuellen EMail-Adressen aus Deutschland! (AOL, T-Online, Vossnet, Compuserve etc. etc.) Unser ADD-ON! (Für die unabhängige professionelle Nutzung) Für nur DM 350.- erhalten Sie das o.g. ADD-ON um selbst auf unbegrenzte Zeit jederzeit EMail-Adressen aus dem Internet holen zu können. Und so funktioniert es: Überweisen Sie DM 250.- für das Enterprise-Paket oder DM 600.- für das Enterprise-Paket inklusive ADD-ON auf das Konto Nummer 98.39.20.761 an die Firma GATEWAY bei der CVB-Bank / Beek in Holland und geben Sie im Überweisungstext (Verwendungszweck) Ihre >> VOLLSTÄNDIGE << EMail-Adresse an. Bitte nicht wundern das die Bankleitzahl (BLZ) fehlt.......In Holland gibt es keine Bankleitzahlen! Nach Zahlungseingang werden wir Ihnen die Software per EMail zustellen.(Dauert ca. 48 Stunden) BITTE ACHTEN SIE DARAUF IHRE EMAIL-ADRESSE SAUBER UND DEUTLICH IN BLOCKSCHRIFT AUF DER ÜBERWEISUNG EINZUTRAGEN! Wir müssen das nämlich lesen können! ----- ----- ----- TarnungsPässe! Die preiswerteste Lebensversicherung,die Sie kaufen können! Die authentischste Identität! Was ist ein Tarnungspaß? Tarnungpässe sehen genauso aus wie ein realer Paß aber der Aussteller ist ein nicht mehr existierendes Land. Wozu benötigen Sie einen Zweitpass? Darwin beachtete, daß die wirkungsvollsten Lebenformulare durch den Gebrauch der Tarnung überlebten. Das Tarnungkonzept ist erstellt worden, um Sie als unbedeutender Tourist aus einem kleinen, harmlosen Land zu kennzeichnen.Er soll nur als Instrument für Ihren persönlichen Schutz verwendet werden. Tatsächlich benutzen viele Regierungsbeamte auch Zweitpässe. Schützen Sie sich vor Terroristen! Zu Zeiten politischer Unruhen könnte ein Tarnungspaß Ihre Lebensdauer sichern. Es gibt Terroristgruppen in praktisch jeder Hauptstadt in der Welt. Eine Reise zur Bank, zum allgemeinen Gebäude, zur militärischen Unterseite oder zur Regierungsstelle könnte eine Geiselsituation werden. Eine Kreuzfahrt zu den Karibischen Meeren könnte in einem Überfall enden. Ein Tarnungpaß gibt Sie mit einer Nullidentität an. Ihre Fänger würden keinen Grund haben, Sie zu schädigen oder als Geisel zu halten. Tarnung zur Rettung! Während des Golfkrieges konnten einige Feldingenieure, das Land auf Tarnungpässen verlassen, die wir sendeten.Sie empfangen eine komplette Geschichte Ihres gewählten Passlandes. Jedoch ist es wichtig, daß Sie logische Beschäftigung und persönliche Geschichte erstellen, um zusammen mit Ihrem Tarnungpaß ein reales Erscheinungsbild abzugeben. Folgende Länder sind vorhanden: . Holländisches Guayana Britische Westinseln Niederlandeostinseln Neu-Hebriden OstSamoa-Inseln Birma Rhodesien Neue Grenada Zanzibar UDSSR Spanische Guine Britisches Guayana SüdVietnam Jeder Zweitpass wird zusammen mit einem FÜHRERSCHEIN geliefert !! . Und so funktioniert es: Überweisen Sie $$ 1000.- auf das Konto Nummer 98.39.20.761 an die Firma GATEWAY bei der CVB-Bank / Beek in Holland und geben Sie im Überweisungstext (Verwendungszweck) Ihre >> VOLLSTÄNDIGE << EMail-Adresse an. Bitte nicht wundern das die Bankleitzahl (BLZ) fehlt.......In Holland gibt es keine Bankleitzahlen! Nach Zahlungseingang werden wir umgehend per EMail Kontakt zu Ihnen aufnehmen um alles weitere zu veranlassen. ----- ----- ----- From gcc-return-9648-listarch-gcc=gcc.gnu.org@gcc.gnu.org Sun Aug 29 22:36:12 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32456 invoked by alias); 29 Aug 1999 22:36:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32437 invoked from network); 29 Aug 1999 22:36:08 -0000 Received: from garfield.dis.com (199.4.97.30) by egcs.cygnus.com with SMTP; 29 Aug 1999 22:36:08 -0000 Received: from garfield (199.4.97.30) by garfield.dis.com (EMWAC SMTPRS 0.81) with SMTP id ; Sun, 29 Aug 1999 15:36:05 -0700 Message-Id: <4.1.19990829152111.00c4f4c0@garfield.dis.com> X-Sender: mark@garfield.dis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 29 Aug 1999 15:36:05 -0700 To: law@cygnus.com From: Mark Klein Subject: Re: MPE Port (was HARD_REGNO_MODE_OK) Cc: gcc@gcc.gnu.org In-Reply-To: <6729.935921331@upchuck.cygnus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 04:08 AM 8/29/99 -0600, Jeffrey A Law wrote: >So let's start with just your new config files and configure.in fragment >first. Can you send just those pieces? Yes. Before I do so, I have one small problem to resolve. Maybe you could provide a suggestion or "better way" to approach it. libio/gen-params tries to determine if __printf_fp() exists by simply compiling a small test program. That is not sufficient on MPE because MPE does late binding. (I run into this with all configure scripts and in discussions with Ben, it was decided that my best approach is to have a customized autoconf and build my own configure scripts before building). That doesn't work here since gen-params is a hard coded script. I don't want to modify it because I'll no doubt break it for all other platforms. Thanks, M. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available From gcc-return-9649-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 07:56:37 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18939 invoked by alias); 30 Aug 1999 07:56:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18924 invoked from network); 30 Aug 1999 07:56:24 -0000 Received: from kwanon.research.canon.com.au (203.12.172.254) by egcs.cygnus.com with SMTP; 30 Aug 1999 07:56:24 -0000 Received: (qmail 1415 invoked from network); 30 Aug 1999 07:55:53 -0000 Received: from eos.research.canon.com.au (203.12.175.190) by kwanon-heat.research.canon.com.au with SMTP; 30 Aug 1999 07:55:53 -0000 Received: from elph.research.canon.com.au (elph.research.canon.com.au [203.12.174.253]) by eos.research.canon.com.au (Postfix) with ESMTP id 3215B42A5 for ; Mon, 30 Aug 1999 17:56:40 +1000 (EST) Received: by elph.research.canon.com.au (Postfix, from userid 157) id 6DB4D708; Mon, 30 Aug 1999 17:55:48 +1000 (EST) Subject: gcc-2.95.1: -Weffc++ is a little too strict about initialization To: gcc@gcc.gnu.org Date: Mon, 30 Aug 1999 17:55:48 +1000 (EST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <19990830075548.6DB4D708@elph.research.canon.com.au> From: greyham@research.canon.com.au (Graham Stoney) Hi folks, The -Weffc++ flag in gcc-2.95.1 warns about constructs which break the rules in Scott Myer's book "Effective C++". This is very cool. Rule 12 is "Prefer initialization to assignment in constructors", so gcc-2.95.1 warns about any member which isn't initialized in the member initialization list. This seem a little excessive for plain old structure members which have no constructor of their own and therefore cannot be initialized in the initialization list. Here is an example with a class containing a POSIX thread mutex, which is a plain old C structure, initialised either by structure assignment or a function call: #include class C { pthread_mutex_t mutex; public: C::C(); }; C::C() { pthread_mutex_init(&mutex, NULL); } gcc-2.95.1 gives: % g++ -Weffc++ weff.cc weff.cc: In method `C::C()': weff.cc:12: warning: `C::mutex' should be initialized in the member initialization list It would be nice if gcc didn't warn about plain structure members which are initialized in a constructor, given that they can't be initialized in the member initialization list. If it weren't for this, I could turn on -Werr too... Thanks, Graham From gcc-return-9650-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 08:18:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20858 invoked by alias); 30 Aug 1999 08:18:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20842 invoked from network); 30 Aug 1999 08:18:13 -0000 Received: from linuxpc1.lauterbach.com (qmailr@194.195.165.177) by egcs.cygnus.com with SMTP; 30 Aug 1999 08:18:13 -0000 Received: (qmail 9840 invoked from network); 30 Aug 1999 08:18:08 -0000 Received: from frapc1.lauterbach.com (HELO frapc1) (192.149.90.33) by linuxpc1 with SMTP; 30 Aug 1999 08:18:08 -0000 Message-Id: <4.2.0.58.19990830094306.047fd8c0@mail.lauterbach.com> X-Sender: fsirl-kernel@mail.lauterbach.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 30 Aug 1999 10:18:04 +0200 To: Bernd Schmidt From: Franz Sirl Subject: Re: Deadly optimization bug (all gcc versions!) Cc: Joern Rennecke ,dje@watson.ibm.com, veksler@il.ibm.com,egcs@egcs.cygnus.com,kenner@vlsi1.ultra.nyu.edu In-Reply-To: References: <99081823080500.00740@ns1102.munich.netsurf.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 16:14 24.08.99 , Bernd Schmidt wrote: >+ /* We can't do anything if the value is set in between the insns we are >+ processing. */ >+ if (INSN_CUID (reg_last_set[regno]) <= INSN_CUID (subst_insn)) >+ return 0; >+ Just for my understanding, reg_last_set[regno] will not point past subst_insn here? What I'm thinking about is, what happens if we have 3 SETs like: SET1 start_of_subst_tree ... SET2 ... subst_insn ... SET3 Will reg_last_set[] point to SET2 or SET3? If it points to SET3, your patch doesn't cover all possibilities, or? Franz. From gcc-return-9651-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 08:47:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23796 invoked by alias); 30 Aug 1999 08:47:09 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23767 invoked from network); 30 Aug 1999 08:47:07 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 30 Aug 1999 08:47:07 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id CAA10418; Mon, 30 Aug 1999 02:37:58 -0600 X-Mailer: exmh version 2.0.2 To: Franz Sirl cc: Bernd Schmidt , Joern Rennecke , dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com, kenner@vlsi1.ultra.nyu.edu Subject: Re: Deadly optimization bug (all gcc versions!) Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 30 Aug 1999 10:18:04 +0200. <4.2.0.58.19990830094306.047fd8c0@mail.lauterbach.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Aug 1999 02:37:58 -0600 Message-ID: <10415.936002278@upchuck.cygnus.com> From: Jeffrey A Law In message <4.2.0.58.19990830094306.047fd8c0@mail.lauterbach.com>you write: > At 16:14 24.08.99 , Bernd Schmidt wrote: > >+ /* We can't do anything if the value is set in between the insns we > are > >+ processing. */ > >+ if (INSN_CUID (reg_last_set[regno]) <= INSN_CUID (subst_insn)) > >+ return 0; > >+ > > Just for my understanding, reg_last_set[regno] will not point past > subst_insn here? What I'm thinking about is, what happens if we have 3 SETs > > like: > > SET1 > start_of_subst_tree > ... > SET2 > ... > subst_insn > ... > SET3 > > Will reg_last_set[] point to SET2 or SET3? If it points to SET3, your patch > doesn't cover all possibilities, or? I don't think reg_last_set can point to set3 since we haven't processed anything beyond subst_insn yet. It can point to SET2, which is the case Bernd's patch is dealing with. jeff From gcc-return-9652-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 08:54:52 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25896 invoked by alias); 30 Aug 1999 08:54:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25880 invoked from network); 30 Aug 1999 08:54:48 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 30 Aug 1999 08:54:48 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id CAA10480; Mon, 30 Aug 1999 02:45:56 -0600 X-Mailer: exmh version 2.0.2 To: Mark Klein cc: gcc@gcc.gnu.org Subject: Re: MPE Port (was HARD_REGNO_MODE_OK) Reply-To: law@cygnus.com In-reply-to: Your message of Sun, 29 Aug 1999 15:36:05 PDT. <4.1.19990829152111.00c4f4c0@garfield.dis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Aug 1999 02:45:56 -0600 Message-ID: <10477.936002756@upchuck.cygnus.com> From: Jeffrey A Law In message <4.1.19990829152111.00c4f4c0@garfield.dis.com>you write: > At 04:08 AM 8/29/99 -0600, Jeffrey A Law wrote: > > >So let's start with just your new config files and configure.in fragment > >first. Can you send just those pieces? > > Yes. Before I do so, I have one small problem to resolve. Maybe you could > provide a suggestion or "better way" to approach it. > > libio/gen-params tries to determine if __printf_fp() exists by simply > compiling a small test program. That is not sufficient on MPE because > MPE does late binding. (I run into this with all configure scripts and > in discussions with Ben, it was decided that my best approach is to > have a customized autoconf and build my own configure scripts before > building). That doesn't work here since gen-params is a hard coded > script. I don't want to modify it because I'll no doubt break it > for all other platforms. This is the kind of issue I'd punt for now. Use some kind of hack in your local tree and we can try to deal with it after we've dealt with the easy stuff. jeff From gcc-return-9653-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 09:03:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27138 invoked by alias); 30 Aug 1999 09:03:45 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27123 invoked from network); 30 Aug 1999 09:03:42 -0000 Received: from linuxpc1.lauterbach.com (qmailr@194.195.165.177) by egcs.cygnus.com with SMTP; 30 Aug 1999 09:03:42 -0000 Received: (qmail 11809 invoked from network); 30 Aug 1999 09:03:34 -0000 Received: from frapc1.lauterbach.com (HELO frapc1) (192.149.90.33) by linuxpc1 with SMTP; 30 Aug 1999 09:03:34 -0000 Message-Id: <4.2.0.58.19990830110013.05c9e3a0@mail.lauterbach.com> X-Sender: fsirl-kernel@mail.lauterbach.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 30 Aug 1999 11:03:31 +0200 To: law@cygnus.com From: Franz Sirl Subject: Re: Deadly optimization bug (all gcc versions!) Cc: Bernd Schmidt , Joern Rennecke ,dje@watson.ibm.com, veksler@il.ibm.com,egcs@egcs.cygnus.com,kenner@vlsi1.ultra.nyu.edu In-Reply-To: <10415.936002278@upchuck.cygnus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:37 30.08.99 , Jeffrey A Law wrote: > In message <4.2.0.58.19990830094306.047fd8c0@mail.lauterbach.com>you write: > > At 16:14 24.08.99 , Bernd Schmidt wrote: > > >+ /* We can't do anything if the value is set in between the > insns we > > are > > >+ processing. */ > > >+ if (INSN_CUID (reg_last_set[regno]) <= INSN_CUID (subst_insn)) > > >+ return 0; > > >+ > > > > Just for my understanding, reg_last_set[regno] will not point past > > subst_insn here? What I'm thinking about is, what happens if we have > 3 SETs > > > > like: > > > > SET1 > > start_of_subst_tree > > ... > > SET2 > > ... > > subst_insn > > ... > > SET3 > > > > Will reg_last_set[] point to SET2 or SET3? If it points to SET3, your > patch > > doesn't cover all possibilities, or? >I don't think reg_last_set can point to set3 since we haven't processed >anything beyond subst_insn yet. > >It can point to SET2, which is the case Bernd's patch is dealing with. Ah, ok. Thanks for the clarification. I was under the impression all this reg_* arrays were computed at the start of combine for the whole function and then updated on-the-fly during combine. Franz. From gcc-return-9654-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 09:04:31 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27571 invoked by alias); 30 Aug 1999 09:04:30 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27544 invoked from network); 30 Aug 1999 09:04:28 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 30 Aug 1999 09:04:28 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id 8461332CE1; Mon, 30 Aug 1999 11:04:00 +0200 (MEST) Received: from Wotan.suse.de (Wotan.suse.de [10.10.0.1]) by Galois.suse.de (Postfix) with ESMTP id 7FFE067A9; Mon, 30 Aug 1999 11:03:59 +0200 (MEST) Received: from hawking.suse.de (Hawking.suse.de [10.10.0.89]) by Wotan.suse.de (Postfix) with ESMTP id A8F507F8B; Mon, 30 Aug 1999 11:03:54 +0200 (MEST) Received: (from schwab@localhost) by hawking.suse.de (8.9.3/8.9.3) id LAA09854; Mon, 30 Aug 1999 11:03:54 +0200 To: Philipp Thomas Cc: Manfred Hollstein , gcc@gcc.gnu.org Subject: Re: code changes and i18n dependencies References: <19990829004958.A11633@Moufang.suse.de> <14281.20449.911081.771040@saturn.hollstein.net> <19990829200307.B1202@Moufang.suse.de> X-Yow: Yow! I'm having a quadraphonic sensation of two winos alone in a steel mill! From: Andreas Schwab Date: 30 Aug 1999 11:03:54 +0200 In-Reply-To: Philipp Thomas's message of "Sun, 29 Aug 1999 20:03:07 +0200" Message-ID: Lines: 23 User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Philipp Thomas writes: |> * Manfred Hollstein (mhollstein@cygnus.com) [19990829 18:05]: |> |> Hi Manfred, |> |> > Could you please describe, |> > |> > (a) how you configured your tree, and |> > (b) what OS you are using? |> > |> |> I can't reproduce it, mostly because I didn't save the original configure |> call. After deleting my build tree and reconfiguring again the error |> vanished. But I'll keep an eye open as I might retrigger it. It is possible that the file was left behind from a previous configure run. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg From gcc-return-9655-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 09:40:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31260 invoked by alias); 30 Aug 1999 09:40:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31220 invoked from network); 30 Aug 1999 09:40:20 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 30 Aug 1999 09:40:20 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id DAA10597; Mon, 30 Aug 1999 03:31:18 -0600 X-Mailer: exmh version 2.0.2 To: Franz Sirl cc: Bernd Schmidt , Joern Rennecke , dje@watson.ibm.com, veksler@il.ibm.com, egcs@egcs.cygnus.com, kenner@vlsi1.ultra.nyu.edu Subject: Re: Deadly optimization bug (all gcc versions!) Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 30 Aug 1999 11:03:31 +0200. <4.2.0.58.19990830110013.05c9e3a0@mail.lauterbach.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Aug 1999 03:31:17 -0600 Message-ID: <10594.936005477@upchuck.cygnus.com> From: Jeffrey A Law In message <4.2.0.58.19990830110013.05c9e3a0@mail.lauterbach.com>you write: > Ah, ok. Thanks for the clarification. I was under the impression all this > reg_* arrays were computed at the start of combine for the whole function > and then updated on-the-fly during combine. Hmmm. Actually, you may have a point. Now you see why I wanted to take another look at the code before I decide on its fate :-) jeff From gcc-return-9656-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 09:51:36 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4536 invoked by alias); 30 Aug 1999 09:51:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4514 invoked from network); 30 Aug 1999 09:51:23 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 30 Aug 1999 09:51:23 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id LAA20587; Mon, 30 Aug 1999 11:51:08 +0200 (MET DST) Date: Mon, 30 Aug 1999 11:51:07 +0200 (MET DST) From: Gerald Pfeifer To: Russ Allbery cc: gcc@gcc.gnu.org Subject: Re: GCC 2.95.x: Major problems on Solaris (was: Lost specific.html FAQEntry) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 28 Aug 1999, Russ Allbery wrote: >> 5. Has someone experiencing these problems already submitted bug reports >> to the binutils developers resp. Sun? > I haven't, under the assumption that the hint file entry in Perl saying > that GNU ld wouldn't work meant that this was a known problem. It might be the case that there were a couple of bugs, so providing some new feedback that it still does not work could prove rather useful. > If people think it would help, I can try it again in a few days and > put together a fuller problem report. Perl makes extensive use of > dynamically loaded modules, and the symptom that I was seeing was that > when all of Perl was linked with GNU ld, it couldn't load the dynamic > modules that it had just built. HJ Lu mentioned that the CVS versions of binutils have a couple of SPARC-related issues fixed, perhaps you can give that a try? (I don't have the URL, but I am sure someone on this list will provide it.) Thanks, Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ From gcc-return-9657-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 09:54:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5761 invoked by alias); 30 Aug 1999 09:54:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5735 invoked from network); 30 Aug 1999 09:54:45 -0000 Received: from rainer.informatik.uni-stuttgart.de (root@129.69.183.1) by egcs.cygnus.com with SMTP; 30 Aug 1999 09:54:45 -0000 Received: from rainer.informatik.uni-stuttgart.de ([127.0.0.1]) by rainer.informatik.uni-stuttgart.de with esmtp (ident rainer using rfc1413) id m11LO99-000HVyC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Mon, 30 Aug 1999 11:54:39 +0200 (CEST) Message-Id: X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: gcc@gcc.gnu.org Subject: Illegal operands with gcc-2.95.1/binutils-2.9.1 on Solaris 2.6 Reply-To: rainer.dorsch@informatik.uni-stuttgart.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Aug 1999 11:54:38 +0300 From: Rainer Dorsch I can't compile this, which compiles perfectly with egcs-1.1.2/SUN as: [rainer@rawu] /tools/CUDD/current/cudd$ gcc -v -c cuddAddApply.c -I../include - O3 -mcpu=ultrasparc -DHAVE_IEEE_754 -DBSD Reading specs from /usr/local/gcc-2.95.1-binutils/lib/gcc-lib/sparc-sun-solari s 2 .6/2.95.1/specs gcc version 2.95.1 19990816 (release) /usr/local/gcc-2.95.1-binutils/lib/gcc-lib/sparc-sun-solaris2.6/2.95.1/cpp -lan g-c -v -I../include -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dsparc -Dsun -Dunix -D__sv r4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D_ _sun -D__unix -Asystem(unix) -Asystem(svr4) -D__OPTIMIZE__ -D__sparc_v9__ -D__GC C_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) -DHAVE_IEEE_754 -DBSD cuddAddApply .c /var/tmp/ccoJrJ10.i GNU CPP version 2.95.1 19990816 (release) (sparc) #include "..." search starts here: #include <...> search starts here: ../include /usr/local/gcc-2.95.1-binutils/include /usr/local/gcc-2.95.1-binutils/lib/gcc-lib/sparc-sun-solaris2.6/2.95.1/../../ . . /../sparc-sun-solaris2.6/include /usr/local/gcc-2.95.1-binutils/lib/gcc-lib/sparc-sun-solaris2.6/2.95.1/includ e /usr/include End of search list. The following default directories have been omitted from the search path: /usr/local/gcc-2.95.1-binutils/lib/gcc-lib/sparc-sun-solaris2.6/2.95.1/../../ . . /../include/g++-3 End of omitted list. /usr/local/gcc-2.95.1-binutils/lib/gcc-lib/sparc-sun-solaris2.6/2.95.1/cc1 /var /tmp/ccoJrJ10.i -quiet -dumpbase cuddAddApply.c -mcpu=ultrasparc -O3 -version -o /var/tmp/ccGy8nV9.s GNU C version 2.95.1 19990816 (release) (sparc-sun-solaris2.6) compiled by GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release). /usr/local/gcc-2.95.1-binutils/sparc-sun-solaris2.6/bin/as -V -Qy -s -xarch=v8p lusa -o cuddAddApply.o /var/tmp/ccGy8nV9.s GNU assembler version 2.9.1 (sparc-sun-solaris2.6), using BFD version 2.9.1 /var/tmp/ccGy8nV9.s: Assembler messages: /var/tmp/ccGy8nV9.s:562: Error: Illegal operands [rainer@rawu] /tools/CUDD/current/cudd$ The assembler code is available at http://www.ra.informatik.uni-stuttgart.de/~rainer/Download/cuddAddApply.s Is this a binutils bug? Thanks. -- Rainer Dorsch Abt. Rechnerarchitektur e-mail:rainer.dorsch@informatik.uni-stuttgart.de Uni Stuttgart Tel.: 0711-7816-215 From gcc-return-9658-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 10:08:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7924 invoked by alias); 30 Aug 1999 10:08:48 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7903 invoked from network); 30 Aug 1999 10:08:43 -0000 Received: from windlord.stanford.edu (171.64.12.23) by egcs.cygnus.com with SMTP; 30 Aug 1999 10:08:43 -0000 Received: (qmail 25198 invoked by uid 50); 30 Aug 1999 10:08:35 -0000 To: Gerald Pfeifer Cc: gcc@gcc.gnu.org Subject: Re: GCC 2.95.x: Major problems on Solaris (was: Lost specific.html FAQEntry) References: From: Russ Allbery In-Reply-To: Gerald Pfeifer's message of "Mon, 30 Aug 1999 11:51:07 +0200 (MET DST)" Date: 30 Aug 1999 03:08:35 -0700 Message-ID: Lines: 32 X-Mailer: Gnus v5.4.66/Emacs 19.34 Gerald Pfeifer writes: > On 28 Aug 1999, Russ Allbery wrote: >>> 5. Has someone experiencing these problems already submitted bug >>> reports to the binutils developers resp. Sun? >> I haven't, under the assumption that the hint file entry in Perl saying >> that GNU ld wouldn't work meant that this was a known problem. > It might be the case that there were a couple of bugs, so providing some > new feedback that it still does not work could prove rather useful. Oh, thanks for following up, I might have forgotten to mention. Since the last message, I sent in some patches to Perl so that it would correctly detect what ld gcc 2.95.1 was using, and ended up looking at the hints file in the development version of Perl. Turns out that the problem these days with GNU ld isn't a bug but rather a difference in behavior between Solaris ld and GNU ld in how they add symbols to the dynamic symbol table. Passing -E to GNU ld is rumored to allow Perl to build correctly. (It's getting to be a full-time job just updating one's mental map of what software packages work where!) I've since moved on to other projects and probably won't have the time to go back and check with GNU ld in the near future, but based on that (and the report of Solaris fixes in the CVS tree), I'll give GNU ld another shot on Solaris the next time I rebuild binutils and gcc. -- Russ Allbery (rra@stanford.edu) From gcc-return-9659-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 10:29:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9695 invoked by alias); 30 Aug 1999 10:29:54 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9650 invoked from network); 30 Aug 1999 10:29:51 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 30 Aug 1999 10:29:51 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id MAA21085; Mon, 30 Aug 1999 12:25:42 +0200 (MET DST) Date: Mon, 30 Aug 1999 12:25:41 +0200 (MET DST) From: Gerald Pfeifer To: Toon Moene cc: Mumit Khan , craig@jcb-sc.com, gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: case of G77 symbol tables In-Reply-To: <37C67A25.4DF8F494@moene.indiv.nluug.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 27 Aug 1999, Toon Moene wrote: >> http://www.fortran.com/fortran/info.html >> >> It has pointers to the FAQ and whole bunch of other stuff. However, I >> don't really know how useful these links are in reality. > We already point to it via the `Readings' section of the GCC Home Page. Yeah, but I wanted to have a direct link for non-GCC Fortran-specific information from the top of our FAQ, where we already had entries for C and C++, to avoid those non-GCC related issues on our lists, yet provide help for those looking for it. I have installed the patch below; thanks for the link(s)! Gerald Index: faq.html =================================================================== RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/faq.html,v retrieving revision 1.145 diff -c -3 -p -r1.145 faq.html *** faq.html 1999/08/24 18:39:41 1.145 --- faq.html 1999/08/30 10:23:19 *************** *** 10,21 **** http://www.gnu.org/software/gcc/faq.html">http://www.gnu.org/software/gcc/faq.html.

    This FAQ tries to answer specific questions concerning GCC. For ! general information regarding C resp. C++, please check the comp.lang.c FAQ, ! comp.lang.c++ FAQ, and the ! comp.std.c++ FAQ.

    --- 10,23 ---- http://www.gnu.org/software/gcc/faq.html">http://www.gnu.org/software/gcc/faq.html.

    This FAQ tries to answer specific questions concerning GCC. For ! general information regarding C, C++, resp. Fortran please check the comp.lang.c FAQ, ! comp.lang.c++ FAQ, ! comp.std.c++ FAQ, and the Fortran Information ! page.

    *************** is declared pure-virtual [class.dtor]/7. *** 1034,1040 ****

    Return to the GCC home page

    !

    Last modified: August 24, 1999

    --- 1036,1042 ----

    Return to the GCC home page

    !

    Last modified: August 30, 1999

    From gcc-return-9660-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 10:43:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11558 invoked by alias); 30 Aug 1999 10:42:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11528 invoked from network); 30 Aug 1999 10:42:53 -0000 Received: from vexpert.dbai.tuwien.ac.at (128.130.111.12) by egcs.cygnus.com with SMTP; 30 Aug 1999 10:42:53 -0000 Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id MAA21444; Mon, 30 Aug 1999 12:42:06 +0200 (MET DST) Date: Mon, 30 Aug 1999 12:42:05 +0200 (MET DST) From: Gerald Pfeifer To: "H.J. Lu" cc: Russ Allbery , gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: GCC 2.95.x: Major problems on Solaris (was: Lost specific.html FAQEntry) In-Reply-To: <19990829000659.7194E8EEE@ocean.lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 28 Aug 1999, H.J. Lu wrote: > There are known bugs in binutils 2.9.1 on Solaris/Sparc. Quite a few > Solaris/Sparc bugs have been fixed in binutils in cvs. Thanks, HJ! I haved installed the patch below; it would be great if someone would drop us a note once binutils have fixed these bugs in an "official" release. Gerald Index: specific.html =================================================================== RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/install/specific.html,v retrieving revision 1.45 diff -r1.45 specific.html 26a27 >
  • sparc-sun-solaris*
    • 444a446,452 >

    sparc-sun-solaris*

    > >

    binutils 2.9.1 has known bugs on this platform. We recommend to use the > vendor tools (Sun as, Sun ld) until these have been fixed.

    > > >
    501c509 <

    Last modified on August 27, 1999.

    --- >

    Last modified on August 30, 1999.

    From gcc-return-9661-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 12:45:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12461 invoked by alias); 30 Aug 1999 12:45:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12433 invoked from network); 30 Aug 1999 12:45:10 -0000 Received: from imo11.mx.aol.com (198.81.17.1) by egcs.cygnus.com with SMTP; 30 Aug 1999 12:45:10 -0000 Received: from N8TM@aol.com by imo11.mx.aol.com (mail_out_v22.4.) id qKFGa07549 (4251); Mon, 30 Aug 1999 08:44:09 -0400 (EDT) From: N8TM@aol.com Message-ID: Date: Mon, 30 Aug 1999 08:44:08 EDT Subject: Re: Illegal operands with gcc-2.95.1/binutils-2.9.1 on Solaris 2.6 To: rainer.dorsch@informatik.uni-stuttgart.de, gcc@gcc.gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows sub 15 The installation instructions need updating, if gcc-2.96 at least requires a more recent binutils than 2.9.1. How about putting the recommended version on mirror sites? Tim tprince@computer.org From gcc-return-9662-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 13:46:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19636 invoked by alias); 30 Aug 1999 13:45:57 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19620 invoked from network); 30 Aug 1999 13:45:56 -0000 Received: from finch-post-12.mail.demon.net (194.217.242.41) by egcs.cygnus.com with SMTP; 30 Aug 1999 13:45:55 -0000 Received: from ascada.demon.co.uk ([158.152.32.23] helo=offy.ascada.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 11LRks-000PeV-0C for gcc@gcc.gnu.org; Mon, 30 Aug 1999 13:45:50 +0000 Received: from radon (radon [194.70.186.192]) by offy.ascada.com (8.8.8/8.8.4) with SMTP id OAA20773 for ; Mon, 30 Aug 1999 14:45:44 +0100 Reply-To: From: "Mike Williams" To: Subject: success Date: Mon, 30 Aug 1999 14:45:29 +0100 Message-ID: <000d01bef2ed$ebf167b0$c0ba46c2@radon.ascada.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Importance: Normal alphaev6-dec-osf4.0f successful. Mike Williams - Systems Manager. Mike@geharris.co.uk These are my own opinions and should not be taken as the opinion of GE Harris Energy Control Systems (UK) Ltd or MPW Solutions Ltd. Tel 01506 402 749 Fax 01506 416 818 From gcc-return-9663-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 14:32:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27140 invoked by alias); 30 Aug 1999 14:32:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27118 invoked from network); 30 Aug 1999 14:32:54 -0000 Received: from 209-249-66-150.snj0.flashcom.net (HELO ocean.lucon.org) (postfix@209.249.66.150) by egcs.cygnus.com with SMTP; 30 Aug 1999 14:32:54 -0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id D548D8EEE; Mon, 30 Aug 1999 07:32:12 -0700 (PDT) Subject: Re: Illegal operands with gcc-2.95.1/binutils-2.9.1 on Solaris 2.6 To: rainer.dorsch@informatik.uni-stuttgart.de Date: Mon, 30 Aug 1999 07:32:12 -0700 (PDT) Cc: gcc@gcc.gnu.org In-Reply-To: from "Rainer Dorsch" at Aug 30, 1999 11:54:38 AM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990830143212.D548D8EEE@ocean.lucon.org> From: hjl@lucon.org (H.J. Lu) > lusa -o cuddAddApply.o /var/tmp/ccGy8nV9.s > GNU assembler version 2.9.1 (sparc-sun-solaris2.6), using BFD version 2.9.1 > /var/tmp/ccGy8nV9.s: Assembler messages: > /var/tmp/ccGy8nV9.s:562: Error: Illegal operands > [rainer@rawu] /tools/CUDD/current/cudd$ > The binutils in CVS works fine. H.J. From gcc-return-9664-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 16:29:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14909 invoked by alias); 30 Aug 1999 16:29:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14889 invoked from network); 30 Aug 1999 16:29:25 -0000 Received: from tower.ti.com (192.94.94.5) by egcs.cygnus.com with SMTP; 30 Aug 1999 16:29:25 -0000 Received: from tilde.csc.ti.com ([157.170.1.149]) by tower.ti.com (8.9.3/8.9.3) with ESMTP id LAA24886; Mon, 30 Aug 1999 11:27:42 -0500 (CDT) Received: from tiuk.ti.com (fantastic.tiuk.ti.com [137.167.91.143]) by tilde.csc.ti.com (8.9.3/8.8.8) with ESMTP id LAA25884; Mon, 30 Aug 1999 11:27:41 -0500 (CDT) Received: from bactrian.ni-s.u-net.com by tiuk.ti.com (8.8.8+Sun/SMI-SVR4) id RAA14767; Mon, 30 Aug 1999 17:27:30 +0100 (BST) Date: Mon, 30 Aug 1999 17:27:30 +0100 (BST) Message-Id: <199908301627.RAA14767@tiuk.ti.com> Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: tkmail-0.011/Perl5 Mail::Internet v1.32 In-Reply-To: from Russ Allbery on 28 Aug 1999 16:48:47 -0700 Subject: Re: GCC 2.95.x: Major problems on Solaris (was: Lost specific.html FAQEntry) To: rra@stanford.edu Cc: Gerald Pfeifer , gcc@gcc.gnu.org References: From: Nick Ing-Simmons Reply-To: Nick Ing-Simmons Russ Allbery writes: >Gerald Pfeifer writes: > >> 5. Has someone experiencing these problems already submitted bug reports >> to the binutils developers resp. Sun? > >I haven't, under the assumption that the hint file entry in Perl saying >that GNU ld wouldn't work meant that this was a known problem. It has been a "known problem" for years. The _original_ problem was GNU ld not honouring LD_RUN_PATH nor -R or equivalent. IIRC the exact problem has varied over the years. There was a version around binutils-2.8.? when it did work, but it was too hard for us to explain to the clueless that they needed to install new binutils and possibly re-build gcc. (Lots of comparitively clueless want to build and use perl.) Now that GNU ld actually gains something (at least for C++) it is worth taking the time to figure it out. >If people >think it would help, I can try it again in a few days and put together a >fuller problem report. Copy to perl5-porters@perl.org too - at very least Configure will probably need tweaks to command line stuff. >Perl makes extensive use of dynamically loaded >modules, and the symptom that I was seeing was that when all of Perl was >linked with GNU ld, it couldn't load the dynamic modules that it had just >built. -- Nick Ing-Simmons From gcc-return-9665-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 16:29:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14971 invoked by alias); 30 Aug 1999 16:29:42 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14955 invoked from network); 30 Aug 1999 16:29:41 -0000 Received: from tower.ti.com (192.94.94.5) by egcs.cygnus.com with SMTP; 30 Aug 1999 16:29:41 -0000 Received: from tilde.csc.ti.com ([157.170.1.149]) by tower.ti.com (8.9.3/8.9.3) with ESMTP id LAA24874; Mon, 30 Aug 1999 11:27:40 -0500 (CDT) Received: from tiuk.ti.com (fantastic.tiuk.ti.com [137.167.91.143]) by tilde.csc.ti.com (8.9.3/8.8.8) with ESMTP id LAA25880; Mon, 30 Aug 1999 11:27:38 -0500 (CDT) Received: from bactrian.ni-s.u-net.com by tiuk.ti.com (8.8.8+Sun/SMI-SVR4) id RAA14769; Mon, 30 Aug 1999 17:27:31 +0100 (BST) Date: Mon, 30 Aug 1999 17:27:31 +0100 (BST) Message-Id: <199908301627.RAA14769@tiuk.ti.com> Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: tkmail-0.011/Perl5 Mail::Internet v1.32 In-Reply-To: from Russ Allbery on 28 Aug 1999 16:48:47 -0700 Subject: Re: GCC 2.95.x: Major problems on Solaris (was: Lost specific.html FAQEntry) To: rra@stanford.edu Cc: Gerald Pfeifer , gcc@gcc.gnu.org References: From: Nick Ing-Simmons Reply-To: Nick Ing-Simmons Russ Allbery writes: >Gerald Pfeifer writes: > >> 5. Has someone experiencing these problems already submitted bug reports >> to the binutils developers resp. Sun? > >I haven't, under the assumption that the hint file entry in Perl saying >that GNU ld wouldn't work meant that this was a known problem. It has been a "known problem" for years. The _original_ problem was GNU ld not honouring LD_RUN_PATH nor -R or equivalent. IIRC the exact problem has varied over the years. There was a version around binutils-2.8.? when it did work, but it was too hard for us to explain to the clueless that they needed to install new binutils and possibly re-build gcc. (Lots of comparitively clueless want to build and use perl.) Now that GNU ld actually gains something (at least for C++) it is worth taking the time to figure it out. >If people >think it would help, I can try it again in a few days and put together a >fuller problem report. Copy to perl5-porters@perl.org too - at very least Configure will probably need tweaks to command line stuff. >Perl makes extensive use of dynamically loaded >modules, and the symptom that I was seeing was that when all of Perl was >linked with GNU ld, it couldn't load the dynamic modules that it had just >built. -- Nick Ing-Simmons From gcc-return-9666-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 17:08:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21312 invoked by alias); 30 Aug 1999 17:07:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21277 invoked from network); 30 Aug 1999 17:07:54 -0000 Received: from mumrik.nada.kth.se (130.237.226.10) by egcs.cygnus.com with SMTP; 30 Aug 1999 17:07:54 -0000 Received: from localhost (d92-foh@localhost) by mumrik.nada.kth.se (8.8.7/8.8.7) with SMTP id TAA12222 for ; Mon, 30 Aug 1999 19:07:47 +0200 (MET DST) Date: Mon, 30 Aug 1999 19:07:46 +0200 (MET DST) From: =?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?= To: gcc@gcc.gnu.org Subject: Recompiling troubles.... Was Re: Strange behaviour in C++... In-Reply-To: <199908291051.MAA00592@mira.isdn.cs.tu-berlin.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 29 Aug 1999, Martin v. Loewis wrote: > http://egcs.cygnus.com/ml/gcc-patches/1999-06/msg00220.html > > It didn't get into 2.95 (as I hoped), and because of Jason's > objections, it didn't go into the mainline, either. Also remember that > the fix introduces a binary incompatibility; so you'd need to use a > command line option to activate it, anyway. In the light of the ia64 I tried to recompile everything with -fno-vtable-thunks, unfortunately now a simple hello world program segfaults somewhere in the iostream library.......... I added -fno-vtable-thunks to MYCXXFLAGS in libstdc++/Makefile.in and recompiled it. Is this the right place to do the change? This is interesting even if I in the future try out the thunk-patch, since I need to recompile the library in that case too. I used CVS to checkout the latest source. How do I apply Martin's patch to my copy? Sorry for my complete lack of knowledge about cvs diffs...... This bug is a showstopper for my project, so I really need a workaround.... :-| (or even better! a fix! ;-) ) Cheers Fredrik From gcc-return-9667-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 17:45:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 25420 invoked by alias); 30 Aug 1999 17:45: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 25402 invoked from network); 30 Aug 1999 17:45:16 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 30 Aug 1999 17:45:16 -0000 Received: from bolero.cs.tu-berlin.de (doko@bolero.cs.tu-berlin.de [130.149.19.1]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id TAA00178 for ; Mon, 30 Aug 1999 19:10:19 +0200 (MET DST) Received: (from doko@localhost) by bolero.cs.tu-berlin.de (8.9.1/8.9.0) id TAA17197; Mon, 30 Aug 1999 19:10:12 +0200 (MET DST) From: Matthias Klose MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 30 Aug 1999 19:09:57 +0200 (MET DST) To: gcc@gcc.gnu.org Subject: mainline shared object name for libstdc++ X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14282.47484.47646.169269@bolero> On a Linux glibc-2.1 based system in the mainline, the shared object name of libstdc++ changed to libstdc++.so.2.10.0 instead of the expected libstdc++-libc6.1-2.so.3 (2.95.1). I cannot see any changes but a sorting of host configurations in libstdc++/configure.in, so I assume it is a "missing feature"? From gcc-return-9668-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 21:12:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19674 invoked by alias); 30 Aug 1999 21:12:40 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 19647 invoked from network); 30 Aug 1999 21:12:34 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 30 Aug 1999 21:12:34 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id XAA01190; Mon, 30 Aug 1999 23:09:24 +0200 Message-ID: <37CAF304.B65C1506@moene.indiv.nluug.nl> Date: Mon, 30 Aug 1999 23:09:24 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: Richard Henderson CC: martin.kahlert@provi.de, egcs@egcs.cygnus.com Subject: Re: g77 performance on ALPHA References: <199908281130.NAA00385@keksy.linux.provi.de> <19990828114410.A29542@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Richard Henderson wrote: > On Sat, Aug 28, 1999 at 01:30:48PM +0200, martin.kahlert@provi.de wrote: > > So i tested with a small daxpy operation: > > SUBROUTINE DAXPY(N,ALPHA,X,I1,Y,I2) > > IMPLICIT NONE > > INTEGER*4 N,I,I1,I2 > > REAL*8 ALPHA,X(N),Y(N) > > > > DO I=1, N > > Y(I)=Y(I)+ALPHA*X(I) > > ENDDO > > RETURN > > END > [...] > > The loop isn't unrolled with -funroll-loops, either. > > Using -funroll-all-loops, we get... > ... at which point we generate the somewhat horid code you saw. Rereading this weekend's thread about g77's performance on the Alpha architecture, something else struck me about the differences in assembly code generated between g77 and Digital's^H^H^H^H^H^HCompaq's Fortran: Our code: $L6: ldt $f10,0($18) ldt $f11,0($20) subq $2,1,$3 addl $2,$31,$1 mult $f12,$f10,$f10 addt $f11,$f10,$f11 stt $f11,0($20) blt $1,$L2 ldt $f10,8($18) ldt $f11,8($20) addl $3,$31,$1 nop mult $f12,$f10,$f10 subq $2,2,$3 addt $f11,$f10,$f11 nop stt $f11,8($20) blt $1,$L2 ldt $f10,16($18) ldt $f11,16($20) addl $3,$31,$1 mult $f12,$f10,$f10 subq $2,3,$3 addt $f11,$f10,$f11 stt $f11,16($20) blt $1,$L2 ldt $f10,24($18) ldt $f11,24($20) addl $3,$31,$1 addq $18,32,$18 mult $f12,$f10,$f10 subq $2,4,$2 addt $f11,$f10,$f11 stt $f11,24($20) addq $20,32,$20 bge $1,$L6 Their code: lab$0004: ldt $f1, ($18) ldt $f10, 8($18) ldt $f11, 16($18) ldt $f12, 24($18) ldt $f13, ($20) ldt $f14, 8($20) ldt $f15, 16($20) ldt $f16, 24($20) mult $f0, $f1, $f1 lda $1, -4($1) mult $f0, $f10, $f10 mult $f0, $f11, $f11 cmple $1, 3, $4 lda $18, 32($18) mult $f0, $f12, $f12 addt $f13, $f1, $f1 lda $20, 32($20) addt $f14, $f10, $f10 addt $f15, $f11, $f11 addt $f16, $f12, $f12 stt $f1, -32($20) stt $f10, -24($20) stt $f11, -16($20) stt $f12, -8($20) beq $4, lab$0004 In addition to the fact that "their code": 1. Doesn't have "nop"s. 2. Misses some extraneous instructions updating the loop counter. 3. Uses lda's instead of addq's to update addresses. 4. Uses a more efficient scheme to deal with the "extra" loop bodies when unrolling (something on my at-least-a-year-old-to-do-list). it also seems to have a different strategy to schedule this code. Just from looking at the unrolled loop, I get the impression that Compaq Fortran's scheduling algorithm tries to minimize conflicts between "loading a value in an FP register" from "reading that FP register" and "writing to an FP register" from "storing from that FP register". Apparently, our scheduler doesn't think it's a good idea to issue all the loads at the top of the loop and all the stores at the bottom ... Is this something that can be expressed in our present (HAIFA) scheduler's framework ? Cheers, -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-9669-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 21:31:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23500 invoked by alias); 30 Aug 1999 21:31:31 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23485 invoked from network); 30 Aug 1999 21:31:27 -0000 Received: from atlrel2.hp.com (156.153.255.202) by egcs.cygnus.com with SMTP; 30 Aug 1999 21:31:27 -0000 Received: from xboibrg4.boi.hp.com (xboibrg4.boi.hp.com [15.56.8.165]) by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id RAA11063 for ; Mon, 30 Aug 1999 17:30:43 -0400 (EDT) Received: by xboibrg4.boi.hp.com with Internet Mail Service (5.5.2448.0) id ; Mon, 30 Aug 1999 15:31:05 -0600 Message-ID: <2FABBD0C77DAD211971F00A0C9DEFC3303AF159C@xboi04.boi.hp.com> From: "EGALITE,ERIC (HP-Boise,ex1)" To: "'gcc@gcc.gnu.org'" Subject: What happened to the -funaligned-pointers option? Date: Mon, 30 Aug 1999 15:30:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" I recently upgraded from "gcc version cygnus-2.7.2-960126" to "gcc version 2.95 1990728 (release)." Version 2.7 supported an option (-funaligned-pointers) that allowed dereferencing unaligned pointers, but version 2.95 regards this as an invalid option. How can I use unaligned pointers with version 2.95? Thanks, Eric Egalite From gcc-return-9670-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 22:52:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 7564 invoked by alias); 30 Aug 1999 22:52:53 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 7549 invoked from network); 30 Aug 1999 22:52:50 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 30 Aug 1999 22:52:50 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id PAA12439; Mon, 30 Aug 1999 15:38:28 -0600 X-Mailer: exmh version 2.0.2 To: "EGALITE,ERIC (HP-Boise,ex1)" cc: "'gcc@gcc.gnu.org'" Subject: Re: What happened to the -funaligned-pointers option? Reply-To: law@cygnus.com In-reply-to: Your message of Mon, 30 Aug 1999 15:30:57 MDT. <2FABBD0C77DAD211971F00A0C9DEFC3303AF159C@xboi04.boi.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Aug 1999 15:38:28 -0600 Message-ID: <12436.936049108@upchuck.cygnus.com> From: Jeffrey A Law In message <2FABBD0C77DAD211971F00A0C9DEFC3303AF159C@xboi04.boi.hp.com>you wr ite: > > I recently upgraded from "gcc version cygnus-2.7.2-960126" to "gcc version > 2.95 1990728 (release)." > > Version 2.7 supported an option (-funaligned-pointers) that allowed > dereferencing unaligned pointers, but version 2.95 regards this as an > invalid option. How can I use unaligned pointers with version 2.95? Only Cygnus releases have ever had the -funaligned-pointers hack. Cygnus has never cleaned up the code and contributed it back to the official gcc distributions. jeff From gcc-return-9671-listarch-gcc=gcc.gnu.org@gcc.gnu.org Mon Aug 30 23:11:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9957 invoked by alias); 30 Aug 1999 23:11:09 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9940 invoked from network); 30 Aug 1999 23:11:07 -0000 Received: from mrwolf.ssd.bctel.net (HELO mrwolf.bctel.net) (204.174.65.129) by egcs.cygnus.com with SMTP; 30 Aug 1999 23:11:07 -0000 Received: (from murrell@localhost) by mrwolf.bctel.net (8.8.8/8.8.8) id QAA13543 for gcc@gcc.gnu.org; Mon, 30 Aug 1999 16:11:05 -0700 (PDT) Message-Id: <199908302311.QAA13543@mrwolf.bctel.net> X-Authentication-Warning: mrwolf.bctel.net: murrell set sender to brian_murrell@bctel.net using -f Date: Mon, 30 Aug 1999 16:11:04 -0700 (PDT) To: gcc@gcc.gnu.org Subject: Can you use global variables in a shared library? X-Mailer: Ishmail 1.3.4-990804-sol MIME-Version: 1.0 Content-Type: text/plain From: "Brian J. Murrell" I am trying to implement my first shared library. I am running on Solaris 2.6 with: $ gcc --version gcc-2.95 $ ld --version GNU ld 2.9.1 Copyright 1997 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. Supported emulations: elf32_sparc I have several .C files which are each compiled with the following command: g++ -c -fPIC -DPIC gen_random_file_name.C -o gen_random_file_name.o -g All of the resulting .o files are linked into a libarary with something like: ld -shared -soname liboca.so.3 -o liboca.so.3 liboca.o String.o gen_random_file_name.o Which is linked to a generic name for teh SO: ln liboca.so.3 liboca.so I then compile a "main()" program into a .o with: g++ -c oca2.C -o oca2.o -g And then link the whole works together with: g++ -g oca2.o -o oca2 -R. -L. -loca static_lib.a -L/usr/local/lib -ltac++ -lsocket++ -lnsl -lsocket -lsocket -lnsl But I get the following error messages while trying to link my main object file with the library: ./liboca.so: undefined reference to `MEMORY_ALLOC_ERROR' So now for details about MEMORY_ALLOC_ERROR. MEMORY_ALLOC_ERROR is a global variable defined in the relevant files as such: gen_random_file_name.C:extern const String MEMORY_ALLOC_ERROR; oca2.h:const String MEMORY_ALLOC_ERROR = "Memalloc error."; and oca2.h is included by oca2.C So, I guess I am left with the question, can you declare a global variable (an extern) in a shared library with the expectation that the object that is linked with the shared library to produce an executable must contain the actual definition of the global variable? If so, any idea what I am doing wrong? b. -- Brian J. Murrell Brian_Murrell@bctel.net BCTel Advanced Communications 604 454 5279 Vancouver, B.C. From gcc-return-9672-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 00:03:22 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 16607 invoked by alias); 31 Aug 1999 00:03:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16582 invoked from network); 31 Aug 1999 00:03:02 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 31 Aug 1999 00:03:02 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id BAA11682; Tue, 31 Aug 1999 01:57:22 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id BAA00794; Tue, 31 Aug 1999 01:53:41 +0200 Date: Tue, 31 Aug 1999 01:53:41 +0200 Message-Id: <199908302353.BAA00794@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: d92-foh@nada.kth.se CC: gcc@gcc.gnu.org In-reply-to: (message from Fredrik =?ISO-8859-1?Q?=D6hrstr=F6m?= on Mon, 30 Aug 1999 19:07:46 +0200 (MET DST)) Subject: Re: Recompiling troubles.... Was Re: Strange behaviour in C++... References: User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > I added -fno-vtable-thunks to MYCXXFLAGS in libstdc++/Makefile.in > and recompiled it. Is this the right place to do > the change? Your best bet is to change the compiler internals altogether; in config/linux.h it says DEFAULT_VTABLE_THUNKS. Unfortunately, with the way Linux libio/stdio/iostream works, you also have to recompile the C library, because it uses thunks as well. > I used CVS to checkout the latest source. How do I apply Martin's > patch to my copy? Sorry for my complete lack of knowledge about cvs > diffs...... I guess the patch doesn't work out-of-the-box; it needs to be updated to the current code. > This bug is a showstopper for my project, so I really need a > workaround.... :-| (or even better! a fix! ;-) ) There is always a work-around: Don't call virtual functions inside destructors. This suggestion may sound strange, but it is meant seriously: If you need to make your code work, it is best to accept the restriction, instead of relying on flaky patches and untested features. Of course, if you are willing to experiment, and if you accept to totally break your compiler, I definitely encourage you to try the patch. To install it, go into the cp directory and invoke patch < patchfile.html (unfortunately, the archive currently makes it difficult to get to the original message, so the patch may fail for that reason as well) Regards, Martin From gcc-return-9673-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 00:53:47 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23327 invoked by alias); 31 Aug 1999 00:53:33 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23296 invoked from network); 31 Aug 1999 00:53:18 -0000 Received: from neon-best.transmeta.com (HELO neon.transmeta.com) (206.184.214.10) by egcs.cygnus.com with SMTP; 31 Aug 1999 00:53:18 -0000 Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id RAA09130 for ; Mon, 30 Aug 1999 17:53:17 -0700 Received: from palladium.transmeta.com (news@palladium.transmeta.com [10.1.1.46]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id RAA09713 for ; Mon, 30 Aug 1999 17:53:16 -0700 (PDT) Received: (from news@localhost) by palladium.transmeta.com (8.8.5/8.8.5) id RAA27194; Mon, 30 Aug 1999 17:53:16 -0700 To: submit-linux-egcs@transmeta.com Path: torvalds From: torvalds@transmeta.com (Linus Torvalds) Newsgroups: linux.egcs Subject: Re: g77 performance on ALPHA Date: 31 Aug 1999 00:53:16 GMT Organization: Transmeta Corporation, Santa Clara, CA Lines: 32 Message-ID: <7qf91s$qhp$1@palladium.transmeta.com> References: <199908281130.NAA00385@keksy.linux.provi.de> <19990828114410.A29542@cygnus.com> <37CAF304.B65C1506@moene.indiv.nluug.nl> NNTP-Posting-Host: cesium.transmeta.com In article <37CAF304.B65C1506@moene.indiv.nluug.nl>, Toon Moene wrote: > >In addition to the fact that "their code": > >1. Doesn't have "nop"s. >2. Misses some extraneous instructions updating the loop counter. >3. Uses lda's instead of addq's to update addresses. >4. Uses a more efficient scheme to deal with the "extra" loop bodies > when unrolling (something on my at-least-a-year-old-to-do-list). None of those look all that noticeable. >it also seems to have a different strategy to schedule this code. ..but this one is. Doing ld+ld+ld+ld -> st+st+st+st is just generally a ton more efficient (if you have the registers, which it does) than doing ld->st + ld->st + ld->st.. and gives much better room for the hardware to optimize things (I suspect that the 21264 doesn't much speculate stores past loads, although who knows - they could check for aliases in hardware). It looks like the Compaq compiler knows the stores cannot alias the loads, while g77 thinks (or tells the instruction scheduler) that the stores could alias and thus they never get moved down. The right schedule should fall out pretty automatically from the load->use and gen->store delays - the fact that gcc has nops is a dead giveaway to show that it's not scheduling very well and it does look like it thinks the stores interfere with the loads. Linus From gcc-return-9674-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 02:38:49 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 2788 invoked by alias); 31 Aug 1999 02:38:36 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 2767 invoked by uid 220); 31 Aug 1999 02:38:28 -0000 Date: 31 Aug 1999 02:38:28 -0000 Message-ID: <19990831023828.2763.qmail@egcs.cygnus.com> From: law@egcs.cygnus.com To: egcs@egcs.cygnus.com Subject: egcs-ss-19990830 is now available egcs-ss-19990830 is now available on egcs.cygnus.com:/pub/egcs/snapshots/1999-08-30 (and on various mirrors, see the egcs home page for mirror sites). You'll find: egcs-19990830.tar.gz The full egcs snapshot, including all languages runtime libraries. egcs-core-19990830.tar.gz Just the C front end and core compiler. egcs-g++-19990830.tar.gz The g++ language and runtime. egcs-g77-19990830.tar.gz The g77 language and runtime. egcs-objc-19990830.tar.gz The Objective-C font end and runtime. egcs-java-19990830.tar.gz The Java font end. egcs-chill-19990830.tar.gz The Chill font end and runtime. Diffs from 19990824 are not available. Note at times you may find newer directories on the server with limited permissions. These represent snapshots that have not yet been verified as correct, or are known to be incorrect. When a particular snapshot is ready for public consumption the directory permissions are relaxed, the LATEST-IS- file is updated and a message is sent to the egcs list. Using a snapshot before it's officially made available is an unwise thing to do since it may become impossible to update to an official snapshot. The "egcs_latest_snapshot" tag has been moved. You can use cvs update -regcs_latest_snapshot to update your CVS tree to the latest official snapshot. From gcc-return-9675-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 02:52:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5024 invoked by alias); 31 Aug 1999 02:52:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4999 invoked from network); 31 Aug 1999 02:51:56 -0000 Received: from mailgate.cadence.com (158.140.2.1) by egcs.cygnus.com with SMTP; 31 Aug 1999 02:51:56 -0000 Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id TAA29155 for ; Mon, 30 Aug 1999 19:51:53 -0700 (PDT) Received: from cds9200.Cadence.COM(158.140.56.18) by mailgate.cadence.com via smap (mjr-v1.2) id xma936067912.029149; Mon, 30 Aug 99 19:51:52 -0700 Received: from pc-john.cadence.com (d1581405822.Cadence.COM [158.140.58.22]) by cds9200.Cadence.COM (8.8.8/8.8.5) with SMTP id TAA27616 for ; Mon, 30 Aug 1999 19:51:51 -0700 (PDT) Message-Id: <199908310251.TAA27616@cds9200.Cadence.COM> X-Sender: john@cds9200 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 30 Aug 1999 19:51:36 -0700 To: gcc@gcc.gnu.org From: John Gianni Subject: Hint: How to install gcc on Solaris (easiest way possible - I think) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dunno - I wrote this apnote below for internal consumption; maybe you might find it useful. It's designed to facilitate the FIRST program a newbie Solaris person ever compiled. All paths are internal. I did it just to see if I could. I don't even have a UNIX workstation, just a PC - I did the same on the PC. jjg **************************************************************************** How to install & test GNU tools on a Sun Solaris Workstation in 15 minutes. Tools installed & tested are gcc, make, & gzip (scores of tools available): A 10-step cut-and-paste walk-thru by John Gianni, version 1.03, 8/29/99 Adapted from: http://www.zdjournals.com/sun/9908/sun9981.htm & http://www.sunfreeware.com/ See also: http://www.gnu.org/ Alternative ftp site: ftp://nce.sun.ca/pub/freeware/ Alternative compiled site: http://sourceware.cygnus.com/ Special thanks to Patrick Pastore for testing & debugging suggestions. **************************************************************************** Note: You may _already_ have a C compiler (cc perhaps?) on your system. An instant locate-exactly will find out in a second, e.g, unix% rsh cds9200 locatex gcc make cc sh (Compare results of 'locatex' with normal 'locate' results.) I _think_ MITS provides the FLEXLM license for cc from Sun: unix% cd /net/iss/scripts/ I _think_ MITS also puts (some?) GNU stuff on new machines by default: unix% netscape http://cdsinfo?-mits+513672 If not... Here is a good example for a person's first GNU tools installation on Sun, which makes use of Sun's 'package installation tools' to ease installation. (Since most of the 15 min. is spent downloading, you should note that MITS has kindly provided easy-to-use GNU installers at /net/iss/scripts/.) Note: GCC used to stand for the GNU C Compiler, but since the compiler now supports several other languages aside from C, it now stands for the GNU Compiler Collection. ============================================================================ Cut-&-paste 10-step Sun Solaris 2.5 "installing basic GNU tools" walk-thru: ============================================================================ SETUP: Make sure you have a /usr/local/bin directory (GNU defaults): unix% su root unix# ls /usr/local/bin If it doesn't exist: unix% mkdir /usr/local/bin Else, check and see if gzip, gcc, & gmake already exist: unix# /usr/local/bin/gzip -V (or /bin/gzip -V) If this reports a version earlier than gzip 1.2.4: unix# mv gzip gzip.`date | awk '{print $6$2$3}'` unix# mv gunzip gunzip.`date | awk '{print $6$2$3}'` unix# /usr/local/bin/gcc -V If this reports a version earlier than 2.8.1: unix# mv gcc gcc.`date | awk '{print $6$2$3}'` unix# /usr/local/bin/gmake -V If this reports a version earlier than 3.77: unix# mv gmake gmake.`date | awk '{print $6$2$3}'` unix# exit ---------------------------------------------------------------------------- STEP 1: Point your web browser to the Sun Freeware site: unix% netscape http://www.sunfreeware.com & Note: It is tremendously easier to install Solaris GNU software from this Sun site, vs from the GNU site (due to pkgadd). (For newbies, we're talkin' minutes, vs hours (or forever).) Note: An alternative, non web site is: unix% ftp nce.sun.ca ---------------------------------------------------------------------------- STEP 2: Make sure your PATH points to "/usr/local/bin": unix% echo $path | grep " /usr/local/bin " If it's not in your path, add it to your path. ---------------------------------------------------------------------------- STEP 3: Create any temporary download directory: unix% mkdir /tmp/download ---------------------------------------------------------------------------- STEP 4: Download "gzip" (gzip-1.2.4a) for your platform into /tmp/download: a) At the www.sunfreeware.com site, select your processor & OS: [SPARC/Solaris 2.5] b) Then, select the latest "gzip" package for your processor & OS: [gzip-1.2.4] c) Save the file to /tmp/download: [gzip-1_2.4 432,128 bytes] Hint: The most consistent way to download, IMHO, is to right-click on the link & "Save As..." (that's how I did it for this note). Note: Otherwise, depending on your Netscape setup, it may save the gzipped file, or, Netscape may automatically unzip it for you. Note: Your version & file size may differ depending on both your OS and the current version of GNU code available. Alternative download (without using a web browser): unix% ftp nce.sun.ca login> anonymous (always use anonymous login) password> john@ (use _your_ login please!) ftp> cd /pub/freeware/sparc/2.5 (use your OS version, if avail.) ftp> !mkdir /tmp/download (create the local directory) ftp> lcd /tmp/download (set the local directory default) ftp> binary (set binary-mode for downloads) ftp> ls gzip* (determine available versions) ftp> prompt (turn off y/n questions for mget) ftp> mget gzip* (multiple-get whatever you want) ftp> quit (quit out of ftp) ---------------------------------------------------------------------------- STEP 5: Install & test GNU "gzip": a) Confirm the file type of the downloaded, unzipped file: unix% file /tmp/download/gzip* This should report something like: gzip-1.2.4: ascii text unix% head /tmp/download/gzip* This should report something like: # PaCkAgE DaTaStReAm FSFgzip 1 928 # end of header NAME=GZIP ARCH=Solaris 2.5 VERSION=1.2.4 CATEGORY=application VENDOR=The Free Software Foundation EMAIL=Jean-loup Gailly etc. b) Install gzip into /usr/local/bin: unix% rlogin localhost -l root (optional if you're already root) unix# cd /tmp/download unix# /usr/sbin/pkgadd -d /tmp/download/gzip* Assent to all defaults. (It will ask you which packages to install; and, it will ask you if it can create a /opt/FSFgzip directory.) Note: the directory name depends on the version, e.g., it may ask to create "/opt/FSFgcc". c) Test the installation: unix# /usr/sbin/pkgchk -d gzip* GNUgzip Note: The capital letters depend on the version downloaded. For example, it may say "... was successful." You'd then need to run: unix# /usr/sbin/pkgchk -d gzip* FSFgzip ---------------------------------------------------------------------------- STEP 6: Download the "make" version for your platform into /tmp/download: a) At the www.sunfreeware.com site, select your processor & OS: [SPARC/Solaris 2.5] b) Then, select the latest "gzip" package for that processor & OS: [make-3.77] c) Save the file to /tmp/download: [make-3_77-sol25-sparc-local.gz 388,836 bytes] Hint: The most consistent way to download, IMHO, is to right-click on the link & "Save As..." (that's how I did it for this note). Note: Otherwise, depending on your Netscape setup, it may save the gzipped file, or, Netscape may automatically unzip it for you. Note: Your version & file size may differ depending on both your OS and the current version of GNU code available. Alternative download (without using a web browser): unix% ftp nce.sun.ca login> anonymous (always use anonymous login) password> john@ (use _your_ login please!) ftp> cd /pub/freeware/sparc/2.5 (use your OS version, if avail.) ftp> !mkdir /tmp/download (create the local directory) ftp> lcd /tmp/download (set the local directory default) ftp> binary (set binary-mode for downloads) ftp> ls make* (determine available versions) ftp> prompt (turn off y/n questions for mget) ftp> mget make* (multiple-get whatever you want) ftp> quit (quit out of ftp) ---------------------------------------------------------------------------- STEP 7: Install & test GNU "make": a) Confirm it; unzip it; and confirm the results: unix% file /tmp/download/make* This should report something like: "make-3.77-sol25-sparc-local.gz: gzip compressed data - deflate method, original file name" unix% gzip -d make* This creates the ASCII package "make-3_77-sol25-sparc-local". Note: This serves as your step 10 'test' of gzip :) unix% head /tmp/download/make* This should report something like: # PaCkAgE DaTaStReAm GNUmake 1 2764 # end of header NAME=make ARCH=sparc VERSION=3.77 CATEGORY=application VENDOR=Free Software Foundation EMAIL=steve@smc.vnet.net etc. b) Install make into /usr/local/bin: unix% rlogin localhost -l root (optional if you're already root) unix# cd /tmp/download unix# /usr/sbin/pkgadd -d make* Assent to the questions, such that, when done, you see: "Installation of was successful." Note: The capital letters depend on the version downloaded. For example, it may say "... was successful." You'd then need to run: unix# /usr/sbin/pkgchk -d make* FSFmake c) Test the installation: unix# /usr/sbin/pkgchk -d make* GNUmake When done, this should report the 3 lines: ## Checking control scripts. ## Checking package objects. ## Checking is complete. d) Rename GNU 'make' to differentiate it from Sun Solaris 'make': unix# mv /usr/local/bin/make /usr/local/bin/gmake ---------------------------------------------------------------------------- STEP 8: Download the GNU C-compiler (gcc): a) At the www.sunfreeware.com site, select your processor & OS: [SPARC/Solaris 2.5] b) Then, select the latest "gcc" package for that processor & OS: [gcc-2.8.1] c) Save the file to /tmp/download: [gcc-2_8_1-local.gz 8,889,454 bytes] Hint: The most consistent way to download, IMHO, is to right-click on the link & "Save As..." (that's how I did it for this note). Note: Otherwise, depending on your Netscape setup, it may save the gzipped file, or, Netscape may automatically unzip it for you. Note: Your version & file size may differ depending on both your OS and the current version of GNU code available. Alternative download (without using a web browser): unix% ftp nce.sun.ca login> anonymous (always use anonymous login) password> john@ (use _your_ login please!) ftp> cd /pub/freeware/sparc/2.5 (use your OS version, if avail.) ftp> !mkdir /tmp/download (create the local directory) ftp> lcd /tmp/download (set the local directory default) ftp> binary (set binary-mode for downloads) ftp> ls gcc* (determine available versions) ftp> prompt (turn off y/n questions for mget) ftp> mget gcc-2.8.1-local.gz (multiple-get whatever you want) ftp> quit (quit out of ftp) ---------------------------------------------------------------------------- STEP 9: Confirm, install & test "gcc": a) Confirm & unzip it: unix% file /tmp/download/gcc* This should report something like: "gcc-2.95-sol25-sparc-local.gz: gzip compressed data - deflate method, original file name" unix% gzip -d gcc* This will create the ASCII package file "gcc-2_8_1-local". unix% head /tmp/download/gcc* This should report something like: # PaCkAgE DaTaStReAm SMCgcc 1 117495 # end of header NAME=gcc ARCH=sparc VERSION=2.95 CATEGORY=application VENDOR=Free Software Foundation EMAIL=steve@smc.vnet.net etc. b) Install gcc into /usr/local/bin: unix% rlogin localhost -l root (optional if you're already root) unix# cd /tmp/download unix# /usr/sbin/pkgadd -d gcc* Assent to all questions; when done, it should say: "Installation of was successful." Note: The capital letters depend on the version downloaded. For example, it may say "... was successful." You'd then need to run: unix# /usr/sbin/pkgchk -d gcc* FSFgcc c) Test the installation: unix# /usr/sbin/pkgchk -d gcc* GNUgcc ---------------------------------------------------------------------------- STEP 10: Test all three executables (in reverse order) on a simple program: a) Test GNU "gcc" on a simple C src program: unix% mkdir /tmp/test unix% vi /tmp/test/hello.c ----< cut here for hello.c >---- #include main() { printf("Hello world.\n"); return 0; } ----< cut here for hello.c >---- unix% rehash unix% gcc /tmp/test/hello.c -o /tmp/test/hello.exe unix% /tmp/test/hello.exe This should report: "Hello world." b) Test GNU "gmake" using a simple Makefile: unix% vi /tmp/test/Makefile ----< cut here for Makefile >---- # Simple Makefile # Choose GNU C-compiler: CC= gcc # Set debugging flags: CFLAGS= -g # Set optimization: CFLAGS= -O2 ----< cut here for Makefile >---- Q: Does anyone have a better simple Makefile example? A: ??? unix% cd /tmp/test unix% gmake hello SHOULD REPORT: gcc -O2 hello.c -o hello And should create: hello unix% ./hello SHOULD REPORT: "Hello world." Note: For a good Cadence DFII Makefile example, look at: `cds_root cds_root`/tools/dfII/pvt/etc/packages/Makefile.obj c) Test GNU "gzip" and "gunzip" on those results: unix% gzip hello.c Makefile This should compress them to hello.c.gz & Makefile.gz unix% rm hello hello.exe Now all you have is the compressed testcases. unix% gunzip hello.c.gz Makefile.gz This should bring you back to your original environment for further tests. **************************************************************************** End of: How to install GNU tools on Sun Solaris in 10 fast cut-&-paste steps. **************************************************************************** From gcc-return-9676-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 03:07:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6570 invoked by alias); 31 Aug 1999 03:07:04 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6555 invoked from network); 31 Aug 1999 03:07:01 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 31 Aug 1999 03:07:01 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id UAA16000 for ; Mon, 30 Aug 1999 20:58:37 -0600 X-Mailer: exmh version 2.0.2 To: egcs@egcs.cygnus.com Subject: Re: egcs-ss-19990830 is now available Reply-To: law@cygnus.com In-reply-to: Your message of 31 Aug 1999 02:38:28 -0000. <19990831023828.2763.qmail@egcs.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Aug 1999 20:58:37 -0600 Message-ID: <15997.936068317@upchuck.cygnus.com> From: Jeffrey A Law In message <19990831023828.2763.qmail@egcs.cygnus.com>I write: > Diffs from 19990824 are not available. A minor fix -- diffs from 19990826 *are* available. I just didn't update the template readme in time :-) jeff From gcc-return-9677-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 04:10:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13147 invoked by alias); 31 Aug 1999 04:10:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13130 invoked from network); 31 Aug 1999 04:10:13 -0000 Received: from surfa.sinewave.com (192.171.80.4) by egcs.cygnus.com with SMTP; 31 Aug 1999 04:10:13 -0000 Received: from wesson (d-0137.SineWave.com [192.171.82.137]) by Surfa.SineWave.com (8.9.3/8.9.3) with ESMTP id VAA10372 for ; Mon, 30 Aug 1999 21:10:02 -0700 Message-Id: <4.2.0.58.19990830210955.00a28100@mail.sinewave.com> X-Sender: bills@mail.sinewave.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 30 Aug 1999 21:10:03 -0700 To: gcc@gcc.gnu.org From: Bill Sheets Subject: Alignment option question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, I am having a problem with gcc forcing alignment of short and long ints in a structure with version 2.8.1 on Solaris on a Sparc system. ie: The struct includes the following fields: . . char rqh_dest_zip [10]; /* 189-198 */ char rqh_dest_state [2]; /* 199-200 */ char filler_2; /* 201 */ long rqh_cod_amount; /* 202-203 */ /* s9(7)v9(2) comp */ long rqh_quote_amount; /* 204-207 */ /* s9(7)v9(2) comp */ . . C code stub: printf ("rqh_dest_zip at %ld\n", (long) ((long) &lpMsg->rqh_dest_zip[0] - nMsgStart)); printf ("rqh_dest_state at %ld\n", (long) ((long) &lpMsg->rqh_dest_state[0] - nMsgStart)); printf ("filler_2 at %ld\n", (long) ((long) &lpMsg->filler_2 - nMsgStart)); printf ("rqh_cod_amount at %ld\n", (long) ((long) &lpMsg->rqh_cod_amount - nMsgStart)); printf ("rqh_quote_amount at %ld\n", (long) ((long) &lpMsg->rqh_quote_amount - nMsgStart)); C output: rqh_dest_zip at 189 rqh_dest_state at 199 filler_2 at 201 rqh_cod_amount at 204 rqh_quote_amount at 208 The problem is that I need 'rqh_cod_amount' to start at the next byte - 202 - instead of being aligned on the next 32bit offset - 204. Is there a compiler option that will disable alignment, so I can manage alignment manually? Regards, Bill From gcc-return-9678-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 04:54:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18015 invoked by alias); 31 Aug 1999 04:54:31 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17998 invoked from network); 31 Aug 1999 04:54:29 -0000 Received: from neon-best.transmeta.com (HELO neon.transmeta.com) (206.184.214.10) by egcs.cygnus.com with SMTP; 31 Aug 1999 04:54:29 -0000 Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id VAA12802 for ; Mon, 30 Aug 1999 21:54:28 -0700 Received: from palladium.transmeta.com (news@palladium.transmeta.com [10.1.1.46]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id VAA20908 for ; Mon, 30 Aug 1999 21:54:28 -0700 (PDT) Received: (from news@localhost) by palladium.transmeta.com (8.8.5/8.8.5) id VAA32478; Mon, 30 Aug 1999 21:54:26 -0700 To: submit-linux-egcs@transmeta.com Path: torvalds From: torvalds@transmeta.com (Linus Torvalds) Newsgroups: linux.egcs Subject: Re: g77 performance on ALPHA Date: 31 Aug 1999 04:54:26 GMT Organization: Transmeta Corporation, Santa Clara, CA Lines: 26 Message-ID: <7qfn62$vmt$1@palladium.transmeta.com> References: <199908281130.NAA00385@keksy.linux.provi.de> <19990828114410.A29542@cygnus.com> <37CAF304.B65C1506@moene.indiv.nluug.nl> <7qf91s$qhp$1@palladium.transmeta.com> NNTP-Posting-Host: cesium.transmeta.com [ ugh, following up on myself ] In article <7qf91s$qhp$1@palladium.transmeta.com>, Linus Torvalds wrote: > >It looks like the Compaq compiler knows the stores cannot alias the >loads, while g77 thinks (or tells the instruction scheduler) that the >stores could alias and thus they never get moved down. Naah, I didn't notice that the gcc output actually has all the compare-and-branch instructions still in the unrolled body of the loop, and those will obviously be serialization points regardless of any aliases: the reason the loads haven't migrated up and the stores down like they should is all those control dependencies. The only way to get close to the compaq compiler is to do the proper iteration unrolling, testing the loop count just once for "4 or more iterations" and then the actual unrolled body would not have any control dependencies. For some reason I thought gcc already did that, but it obviously doesn't. Strange. Without doing that there isn't all that much point in unrolling in the first place - you increase your icache footprint without really improving the code all that much. Linus From gcc-return-9679-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 05:31:29 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20547 invoked by alias); 31 Aug 1999 05:31:24 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20531 invoked from network); 31 Aug 1999 05:31:20 -0000 Received: from windlord.stanford.edu (171.64.12.23) by egcs.cygnus.com with SMTP; 31 Aug 1999 05:31:20 -0000 Received: (qmail 28507 invoked by uid 50); 31 Aug 1999 05:31:10 -0000 To: Nick Ing-Simmons Cc: Gerald Pfeifer , gcc@gcc.gnu.org Subject: Re: GCC 2.95.x: Major problems on Solaris References: <199908301627.RAA14769@tiuk.ti.com> From: Russ Allbery In-Reply-To: Nick Ing-Simmons's message of "Mon, 30 Aug 1999 17:27:31 +0100 (BST)" Date: 30 Aug 1999 22:31:10 -0700 Message-ID: Lines: 12 X-Mailer: Gnus v5.4.66/Emacs 19.34 Nick Ing-Simmons writes: > Copy to perl5-porters@perl.org too - at very least Configure will > probably need tweaks to command line stuff. Andy says that adding -E to the link options, which is in the _61 hints file, makes Perl build correctly with GNU ld, and that he got a bunch of positive confirmations back in April. So it's possible that this is now fixed. -- Russ Allbery (rra@stanford.edu) From gcc-return-9680-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 06:41:01 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28445 invoked by alias); 31 Aug 1999 06:40:52 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28422 invoked from network); 31 Aug 1999 06:40:46 -0000 Received: from 09-061.015.popsite.net (HELO tandbserver) (198.79.106.61) by egcs.cygnus.com with SMTP; 31 Aug 1999 06:40:46 -0000 From: T & B Associates To: Message-Id: <419.436402.98671863macbob@mailcity.com> Subject: 9,000,000 "*BYTEBLE" email addresses PLUS! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit LIMITED TIME OFFER!! OVER 9,000,000 eMail addresses in easy to manage byte size folders of 32,000 addresses each. *To be removed from this list FAX printed or typed email address to 419 715-9641. >>>ONLY $19.95 (US) Cash (US $20), Check , Money Order, Mastercard or Visa + $2.95 shipping & handling ( I pay shipping on cash orders) CA residents add $1.50 Sales Tax.<<< + PLUS! Order now and we'll throw in FREE, 2 bulk email sending and management programs AND a FREE zip program. Why *bytebles is so great??? Did you know that Windows 95 is only capable of managing lists as long as 32000. So if your trying to manage lists larger than this you will have problems. "*Bytebles" is already in byte size portions making it easier to use. Also many email programs and some pc's will crash if you try to load in some of the large lists available. ALSO- all addresses are US only and all domains are com or net. All software and "byteble" lists come packaged on a CD ROM in a Jewel Case. ORDER NOW... Send Cash, Check or Money Order to address below or print this form and fax Credit Card Info. See form below. Be sure to include: NAME, ADDRESS, CITY, ST, ZIP and please include your email address in case we need to contact you. NOTE: Packages inferior to this one are selling for over $295.00 Make check or M.O. payable to: ~~~~~~~~~~~~~~~~~~~~ T & B Associates 112 Harvard Avenue, Suite 84 Claremont, CA 91711 909 605-6233 419 715-9641 (fax) *"Bytebles" is a registered trademark of T & B Associates - - - - - - - - - - - Credit Card Form - - - - - - - - - - - - - - - - - NAME:_________________________________ ADDRESS:_________________________ CITY/ST/ZIP_________________________ TYPE OF CARD (m/c,visa,discover)_________ EXP DATE (MM/YY)____________ TELEPHONE ( ) ____ ________ EMAIL ADDRESS ____________________________ Print and FAX to (419) 715-9641 To place your ORDER by phone please CALL 1-800 483-0094 ext 4942228. To be REMOVED from this list FAX printed or typed email address to 419 715-9641. From gcc-return-9681-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 07:38:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 6770 invoked by alias); 31 Aug 1999 07:37:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 6744 invoked from network); 31 Aug 1999 07:37:37 -0000 Received: from mumrik.nada.kth.se (130.237.226.10) by egcs.cygnus.com with SMTP; 31 Aug 1999 07:37:37 -0000 Received: from localhost (d92-foh@localhost) by mumrik.nada.kth.se (8.8.7/8.8.7) with SMTP id JAA22121; Tue, 31 Aug 1999 09:37:32 +0200 (MET DST) Date: Tue, 31 Aug 1999 09:37:31 +0200 (MET DST) From: =?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?= To: "Martin v. Loewis" cc: gcc@gcc.gnu.org Subject: Re: Recompiling troubles.... Was Re: Strange behaviour in C++... In-Reply-To: <199908302353.BAA00794@mira.isdn.cs.tu-berlin.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 31 Aug 1999, Martin v. Loewis wrote: > Your best bet is to change the compiler internals altogether; in > config/linux.h it says DEFAULT_VTABLE_THUNKS. OK, > Unfortunately, with the way Linux libio/stdio/iostream works, you also > have to recompile the C library, because it uses thunks as well. The glibc library? Arggggg..... > There is always a work-around: Don't call virtual functions inside > destructors. This suggestion may sound strange, but it is meant > seriously: If you need to make your code work, it is best to accept > the restriction, instead of relying on flaky patches and untested > features. Of course, if you are willing to experiment, and if you > accept to totally break your compiler, I definitely encourage you to > try the patch. To install it, go into the cp directory and invoke Hmmm, I am not calling any virtual functions in destructors. I assume you meant constructors. Anyway, that is not an option. I use CORBA which means a lot of abstract (virtual) base classes that defines interfaces. The cast to an interface class is not done by me but implicitly when I call another method which only takes a pointer to such an interface as an argument. > patch < patchfile.html Ok, so I'll run it in the cp directory. Thanks. //Fredrik From gcc-return-9682-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 08:14:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 14501 invoked by alias); 31 Aug 1999 08:14:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14471 invoked from network); 31 Aug 1999 08:14:04 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 31 Aug 1999 08:14:04 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id 87B9932CDA; Tue, 31 Aug 1999 10:13:36 +0200 (MEST) Received: from Wotan.suse.de (Wotan.suse.de [10.10.0.1]) by Galois.suse.de (Postfix) with ESMTP id 282A067A9; Tue, 31 Aug 1999 10:13:36 +0200 (MEST) Received: from hawking.suse.de (Hawking.suse.de [10.10.0.89]) by Wotan.suse.de (Postfix) with ESMTP id 750E87F8B; Tue, 31 Aug 1999 10:13:35 +0200 (MEST) Received: (from schwab@localhost) by hawking.suse.de (8.9.3/8.9.3) id KAA31256; Tue, 31 Aug 1999 10:13:35 +0200 To: Matthias Klose Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: mainline shared object name for libstdc++ References: <14282.47484.47646.169269@bolero> X-Yow: Yow! From: Andreas Schwab Date: 31 Aug 1999 10:13:35 +0200 In-Reply-To: Matthias Klose's message of "Mon, 30 Aug 1999 19:09:57 +0200 (MET DST)" Message-ID: Lines: 42 User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Matthias Klose writes: |> On a Linux glibc-2.1 based system in the mainline, the shared object |> name of libstdc++ changed to libstdc++.so.2.10.0 instead of the |> expected libstdc++-libc6.1-2.so.3 (2.95.1). I cannot see any changes |> but a sorting of host configurations in libstdc++/configure.in, so I |> assume it is a "missing feature"? The matches are not exclusive, thus they must not be sorted alphabetically. 1999-08-31 Andreas Schwab * configure.in: Move *-*-gnu* pattern below *-*-linux*. Index: libstdc++/configure.in =================================================================== RCS file: /egcs/carton/cvsfiles/egcs/libstdc++/configure.in,v retrieving revision 1.29 diff -u -a -u -r1.29 libstdc++/configure.in --- libstdc++/configure.in 1999/08/25 07:33:08 1.29 +++ libstdc++/configure.in 1999/08/31 08:11:55 @@ -71,11 +71,12 @@ *-dec-osf*) frags="${frags} dec-osf.ml";; *-*-freebsd2*) ;; *-*-freebsd*) frags="${frags} freebsd.ml" ;; - *-*-gnu*) frags="${frags} gnu.ml" ;; *-*-hpux*) frags="${frags} hpux.ml" ;; *-*-irix[56]*) frags="${frags} irix5.ml" ;; *-*-linux*aout*) ;; *-*-linux*) frags="${frags} linux.ml" ;; + # This must come after *-*-linux* + *-*-gnu*) frags="${frags} gnu.ml" ;; *-*-openbsd*) frags="${frags} openbsd.ml" ;; *-*-sysv[45]*|*-*-udk*) frags="${frags} elf.ml" ;; *-*-solaris*) frags="${frags} sol2shm.ml" ;; -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg From gcc-return-9683-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 09:13:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22498 invoked by alias); 31 Aug 1999 09:13:51 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22478 invoked from network); 31 Aug 1999 09:13:46 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 31 Aug 1999 09:13:46 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id LAA21721; Tue, 31 Aug 1999 11:07:26 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id LAA00505; Tue, 31 Aug 1999 11:07:21 +0200 Date: Tue, 31 Aug 1999 11:07:21 +0200 Message-Id: <199908310907.LAA00505@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: d92-foh@nada.kth.se CC: gcc@gcc.gnu.org In-reply-to: (message from Fredrik =?ISO-8859-1?Q?=D6hrstr=F6m?= on Tue, 31 Aug 1999 09:37:31 +0200 (MET DST)) Subject: Re: Recompiling troubles.... Was Re: Strange behaviour in C++... References: User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII [calling virtual functions in destructors] > Hmmm, I am not calling any virtual functions in destructors. I assume > you meant constructors. Yes, either constructors, or destructors. > Anyway, that is not an option. I use CORBA which means a lot of > abstract (virtual) base classes that defines interfaces. The cast to > an interface class is not done by me but implicitly when I call > another method which only takes a pointer to such an interface as an > argument. There is no problem with casting to a virtual base. The problem only shows up when this virtual base pointer is used to invoke a virtual function, and this call, directly or indirectly, appears in the constructor of the derived class. Since it is you who writes the constructor of the derived class, it seems that you can control very well what you are calling. Regards, Martin From gcc-return-9684-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 09:49:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 29975 invoked by alias); 31 Aug 1999 09:49:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 29937 invoked from network); 31 Aug 1999 09:49:02 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 31 Aug 1999 09:49:02 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id D156F32CDB for ; Tue, 31 Aug 1999 11:48:34 +0200 (MEST) Received: from jeffreys.suse.de (Jeffreys.suse.de [10.0.0.133]) by Galois.suse.de (Postfix) with ESMTP id BEB3267B4 for ; Tue, 31 Aug 1999 11:48:34 +0200 (MEST) Received: (from pthomas@localhost) by jeffreys.suse.de (8.9.3/8.9.3) id LAA01318 for gcc@gcc.gnu.org; Tue, 31 Aug 1999 11:48:34 +0200 Date: Tue, 31 Aug 1999 11:48:34 +0200 From: Philipp Thomas To: gcc@gcc.gnu.org Subject: Re: mainline shared object name for libstdc++ Message-ID: <19990831114834.G836@jeffreys.suse.de> Mail-Followup-To: gcc@gcc.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i > The matches are not exclusive, thus they must not be sorted > alphabetically. This is really strange, as the libstdc++ configure.in in my 2.95.1 tarball dos have them in correct order. But anyway, the missing libc-version must have other reasons. -- Philipp Thomas close the window - the penguin is freezing ------------------------------------------------------------ SuSE GmbH, Tel: +49-911-7405330 Schanzaeckerstr. 10, Fax: +49-911-3206727 90443 Nuernberg, WWW: http://www.suse.de Germany ------------------------------------------------------------ From gcc-return-9685-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 10:08:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31961 invoked by alias); 31 Aug 1999 10:08:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31940 invoked from network); 31 Aug 1999 10:07:54 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 31 Aug 1999 10:07:54 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id 42A2532CDB for ; Tue, 31 Aug 1999 12:07:25 +0200 (MEST) Received: from Wotan.suse.de (Wotan.suse.de [10.10.0.1]) by Galois.suse.de (Postfix) with ESMTP id 0335767F7 for ; Tue, 31 Aug 1999 12:07:24 +0200 (MEST) Received: from hawking.suse.de (Hawking.suse.de [10.10.0.89]) by Wotan.suse.de (Postfix) with ESMTP id C87E37F8B; Tue, 31 Aug 1999 12:07:24 +0200 (MEST) Received: (from schwab@localhost) by hawking.suse.de (8.9.3/8.9.3) id MAA17499; Tue, 31 Aug 1999 12:07:24 +0200 To: Philipp Thomas Cc: gcc@gcc.gnu.org Subject: Re: mainline shared object name for libstdc++ References: <19990831114834.G836@jeffreys.suse.de> X-Yow: An air of FRENCH FRIES permeates my nostrils!! From: Andreas Schwab Date: 31 Aug 1999 12:07:24 +0200 In-Reply-To: Philipp Thomas's message of "Tue, 31 Aug 1999 11:48:34 +0200" Message-ID: Lines: 20 User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Philipp Thomas writes: |> > The matches are not exclusive, thus they must not be sorted |> > alphabetically. |> |> This is really strange, as the libstdc++ configure.in in my 2.95.1 tarball |> dos have them in correct order. That's not strange in any way, 2.95.1 does not support *-*-gnu*. |> But anyway, the missing libc-version must have other reasons. There is no other reason. Andreas. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg From gcc-return-9686-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 10:45:12 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1327 invoked by alias); 31 Aug 1999 10:45:07 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1310 invoked from network); 31 Aug 1999 10:45:02 -0000 Received: from cantor.suse.de (194.112.123.193) by egcs.cygnus.com with SMTP; 31 Aug 1999 10:45:02 -0000 Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by Cantor.suse.de (Postfix) with ESMTP id 3235632CDA for ; Tue, 31 Aug 1999 12:44:35 +0200 (MEST) Received: from Wotan.suse.de (Wotan.suse.de [10.10.0.1]) by Galois.suse.de (Postfix) with ESMTP id 973A767B4 for ; Tue, 31 Aug 1999 12:44:34 +0200 (MEST) Received: from hawking.suse.de (Hawking.suse.de [10.10.0.89]) by Wotan.suse.de (Postfix) with ESMTP id CB7E07F8B; Tue, 31 Aug 1999 12:44:34 +0200 (MEST) Received: (from schwab@localhost) by hawking.suse.de (8.9.3/8.9.3) id MAA32613; Tue, 31 Aug 1999 12:44:34 +0200 To: gcc@gcc.gnu.org Subject: Re: mainline shared object name for libstdc++ References: <19990831114834.G836@jeffreys.suse.de> X-Yow: Life is selling REVOLUTIONARY HAIR PRODUCTS! From: Andreas Schwab Date: 31 Aug 1999 12:44:34 +0200 In-Reply-To: Andreas Schwab's message of "31 Aug 1999 12:07:24 +0200" Message-ID: Lines: 12 User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I wrote: |> That's not strange in any way, 2.95.1 does not support *-*-gnu*. This is of course wrong, I have missed the line in the 2.95 branch. Andreas. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg From gcc-return-9687-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 11:15:08 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4524 invoked by alias); 31 Aug 1999 11:14:59 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4505 invoked from network); 31 Aug 1999 11:14:52 -0000 Received: from winds.org (root@216.190.230.155) by egcs.cygnus.com with SMTP; 31 Aug 1999 11:14:52 -0000 Received: from localhost (gandalf@localhost) by winds.org (8.9.3/8.9.3) with ESMTP id HAA04559 for ; Tue, 31 Aug 1999 07:14:30 -0400 Date: Tue, 31 Aug 1999 07:14:30 -0400 (EDT) From: Byron Stanoszek To: gcc@gcc.gnu.org Subject: Successful build of gcc on new beta OSF5.0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've successfully built gcc 2.95.1 on Compaq's publicly-available test drive site (http://testdrive.compaq.com) running a beta version of osf5.0 by using the same specs as the latest 4.0[ab] under configure; alphaev6-dec-osf5.0 --- Byron Stanoszek Network Administrator, University of Akron Applied Math Dept. From gcc-return-9688-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 12:34:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 28337 invoked by alias); 31 Aug 1999 12:34:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 28320 invoked from network); 31 Aug 1999 12:34:21 -0000 Received: from imo26.mx.aol.com (198.81.17.70) by egcs.cygnus.com with SMTP; 31 Aug 1999 12:34:21 -0000 Received: from N8TM@aol.com by imo26.mx.aol.com (mail_out_v22.4.) id qQRAa01827 (4255); Tue, 31 Aug 1999 08:33:06 -0400 (EDT) From: N8TM@aol.com Message-ID: <833a759d.24fd2581@aol.com> Date: Tue, 31 Aug 1999 08:33:05 EDT Subject: Re: g77 performance on ALPHA To: torvalds@transmeta.com, submit-linux-egcs@transmeta.com CC: gcc@gcc.gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows sub 22 In a message dated 8/30/99 11:55:55 PM EST, torvalds@transmeta.com writes: > do the proper > iteration unrolling, testing the loop count just once for "4 or more > iterations" and then the actual unrolled body would not have any control > dependencies. > > For some reason I thought gcc already did that, but it obviously > doesn't That's the difference between "unroll-loops" (if the compiler is willing) and "unroll-all-loops." From gcc-return-9689-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 14:37:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 22499 invoked by alias); 31 Aug 1999 14:37:07 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 22479 invoked from network); 31 Aug 1999 14:37:05 -0000 Received: from vss26.vss.fsi.com (HELO esds.vss.fsi.com) (199.217.137.156) by egcs.cygnus.com with SMTP; 31 Aug 1999 14:37:05 -0000 Received: from eos.vss.fsi.com (eos.vss.fsi.com [198.51.27.130]) by esds.vss.fsi.com (8.9.1a/8.9.1) with ESMTP id JAA27665; Tue, 31 Aug 1999 09:35:26 -0500 (CDT) Received: from localhost (ford@localhost) by eos.vss.fsi.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA14242; Tue, 31 Aug 1999 09:34:07 -0500 (CDT) X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Tue, 31 Aug 1999 09:34:07 -0500 (CDT) From: Brian Ford X-Sender: ford@eos To: rainer.dorsch@informatik.uni-stuttgart.de cc: gcc@gcc.gnu.org Subject: Re: Building binutils on Solaris In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have coppied the gcc@gcc.gnu.org mailing list. You should really ask your questions there so more people will have the opportunity to answer. I'm not really a SPARC or GCC expert, so you might get better replies there. On Tue, 31 Aug 1999, Rainer Dorsch wrote: > If I want that gcc/g++ optimize as good as possible for an Ultrasparc > processor by default (i.e. without telling -mcpu=ultrasparc), which > configuration option should I give? > I am still rassling with this one myself. Maybe someone on the list will know better than I? Since -mcpu=ultrasparc requires either the Solaris as and ld, or a newer than release version of the GNU binutils, and it has certain codegen bugs and internal compiler errors, it obviosly doesn't work. I think -mcpu=supersparc might be more stable and give you some optimizations. See the gcc info pages under: Invoking GCC -> Submodel Options -> SPARC options for a description of all that are available. > Should I say > > --target=sparcv9 > > when configuring? > No! I believe that this implies the 64 bit architecture and I am sure that is not ready for mass consumption. -- Brian Ford Software Engineer Vital Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 From gcc-return-9690-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 15:03:02 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27843 invoked by alias); 31 Aug 1999 15:03:01 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27810 invoked from network); 31 Aug 1999 15:02:58 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 31 Aug 1999 15:02:58 -0000 Received: (qmail 23953 invoked by alias); 31 Aug 1999 15:02:56 -0000 Received: (qmail 23943 invoked from network); 31 Aug 1999 15:02:55 -0000 Received: from pathia.cygnus.co.uk (nickc@194.130.39.20) by dns.cygnus.co.uk with SMTP; 31 Aug 1999 15:02:55 -0000 Received: (from nickc@localhost) by pathia.cygnus.co.uk (8.8.7/8.8.7) id QAA16056; Tue, 31 Aug 1999 16:02:49 +0100 Date: Tue, 31 Aug 1999 16:02:49 +0100 Message-Id: <199908311502.QAA16056@pathia.cygnus.co.uk> X-Authentication-Warning: pathia.cygnus.co.uk: nickc set sender to nickc@cygnus.com using -f From: Nick Clifton To: rainer.dorsch@informatik.uni-stuttgart.de CC: gcc@gcc.gnu.org Subject: Re: Building binutils on Solaris Reply-to: nickc@cygnus.co.uk Hi Rainer, : > If I want that gcc/g++ optimize as good as possible for an Ultrasparc : > processor by default (i.e. without telling -mcpu=ultrasparc), which : > configuration option should I give? : > : : I am still rassling with this one myself. Maybe someone on the list : will know better than I? Since -mcpu=ultrasparc requires either the : Solaris as and ld, or a newer than release version of the GNU binutils, : and it has certain codegen bugs and internal compiler errors, it obviosly : doesn't work. I think -mcpu=supersparc might be more stable and give you : some optimizations. See the gcc info pages under: : Invoking GCC -> Submodel Options -> SPARC options for a description of all : that are available. Can't you use --with-cpu=ultrasparc when configuring, so that the default cpu will be the ultrasparc ? Cheers Nick From gcc-return-9691-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 15:30:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32150 invoked by alias); 31 Aug 1999 15:30:40 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32124 invoked from network); 31 Aug 1999 15:30:36 -0000 Received: from vss26.vss.fsi.com (HELO esds.vss.fsi.com) (199.217.137.156) by egcs.cygnus.com with SMTP; 31 Aug 1999 15:30:36 -0000 Received: from eos.vss.fsi.com (eos.vss.fsi.com [198.51.27.130]) by esds.vss.fsi.com (8.9.1a/8.9.1) with ESMTP id KAA28606; Tue, 31 Aug 1999 10:28:55 -0500 (CDT) Received: from localhost (ford@localhost) by eos.vss.fsi.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA15690; Tue, 31 Aug 1999 10:27:36 -0500 (CDT) X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Tue, 31 Aug 1999 10:27:36 -0500 (CDT) From: Brian Ford X-Sender: ford@eos To: nickc@cygnus.co.uk cc: rainer.dorsch@informatik.uni-stuttgart.de, gcc@gcc.gnu.org Subject: Re: Building binutils on Solaris In-Reply-To: <199908311502.QAA16056@pathia.cygnus.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 31 Aug 1999, Nick Clifton wrote: > Rainer wrote: > > : > If I want that gcc/g++ optimize as good as possible for an Ultrasparc > : > processor by default (i.e. without telling -mcpu=ultrasparc), which > : > configuration option should I give? > : > > : > : Brian Ford wrote: > : > : I am still rassling with this one myself. Maybe someone on the list > : will know better than I? Since -mcpu=ultrasparc requires either the > : Solaris as and ld, or a newer than release version of the GNU binutils, > : and it has certain codegen bugs and internal compiler errors, it obviosly > : doesn't work. I think -mcpu=supersparc might be more stable and give you > : some optimizations. See the gcc info pages under: > : Invoking GCC -> Submodel Options -> SPARC options for a description of all > : that are available. > > Can't you use --with-cpu=ultrasparc when configuring, so that the > default cpu will be the ultrasparc ? > Yes, but per the discussion above, this results in a mostly broken compiler. I was suggesting, only not clear enough, to use --with-cpu=supersparc as it might be more stable. -- Brian Ford Software Engineer Vital Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 From gcc-return-9692-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 15:43:46 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 1707 invoked by alias); 31 Aug 1999 15:43:40 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 1683 invoked from network); 31 Aug 1999 15:43:37 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 31 Aug 1999 15:43:37 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA18017; Tue, 31 Aug 1999 08:43:35 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id IAA09158; Tue, 31 Aug 1999 08:43:34 -0700 (PDT) Date: Tue, 31 Aug 1999 08:43:34 -0700 (PDT) Message-Id: <199908311543.IAA09158@kankakee.wrs.com> To: bills@ziadesigns.com, gcc@gcc.gnu.org Subject: Re: Alignment option question Yes, please read the manual (*.texi) that we spent considerable time writting for you. Look for the word pack. Also, if you rearrange the elements, so the longs are first, it will just work. > Date: Mon, 30 Aug 1999 21:10:03 -0700 > To: gcc@gcc.gnu.org > From: Bill Sheets > I am having a problem with gcc forcing alignment of short > and long ints in a structure with version 2.8.1 on Solaris > on a Sparc system. From gcc-return-9693-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 16:11:34 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8848 invoked by alias); 31 Aug 1999 16:11:31 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8813 invoked by uid 9012); 31 Aug 1999 16:11:27 -0000 Message-ID: <19990831161127.8812.qmail@egcs.cygnus.com> From: korbb@egcs.cygnus.com Subject: gperf F option? To: gcc@gcc.gnu.org, gcc-bugs@egcs.cygnus.com, autogen@linuxbox.com Date: Tue, 31 Aug 1999 09:11:26 -0700 (PDT) Reply-To: "Bruce Korb" Content-Type: text From gcc-return-9694-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 16:19:03 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11380 invoked by alias); 31 Aug 1999 16:19:00 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11347 invoked by uid 9012); 31 Aug 1999 16:18:58 -0000 Message-ID: <19990831161858.11346.qmail@egcs.cygnus.com> From: korbb@egcs.cygnus.com Subject: gperf F option? To: gcc@gcc.gnu.org, gcc-bugs@egcs.cygnus.com, autogen@linuxbox.com Date: Tue, 31 Aug 1999 09:18:58 -0700 (PDT) Reply-To: "Bruce Korb" Content-Type: text While building gcc (egcs): [[...]] ln cccp cpp gperf -L C -F ', 0, 0' -p -j1 -i 1 -g -o -t -G -N is_reserved_word \ -k1,3,$ ../../egcs/gcc/c-parse.gperf >tmp-gperf.h gperf: invalid option -- F Usage: gperf [-cCdDef[num]GhHiIjkKlLnNorsStTvWZ7] [input-file] Try `gperf --help' for more information. make[1]: *** [../../egcs/gcc/c-gperf.h] Error 1 make[1]: Leaving directory `/home/bkorb/tools/egcs/main/=build/gcc' make: *** [all-gcc] Error 2 /home/bkorb/tools/egcs/main/=build $ gperf --version GNU gperf 2.7 From gcc-return-9695-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 16:24:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12920 invoked by alias); 31 Aug 1999 16:24:32 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12904 invoked from network); 31 Aug 1999 16:24:27 -0000 Received: from vss26.vss.fsi.com (HELO esds.vss.fsi.com) (199.217.137.156) by egcs.cygnus.com with SMTP; 31 Aug 1999 16:24:27 -0000 Received: from eos.vss.fsi.com (eos.vss.fsi.com [198.51.27.130]) by esds.vss.fsi.com (8.9.1a/8.9.1) with ESMTP id LAA29639; Tue, 31 Aug 1999 11:22:43 -0500 (CDT) Received: from localhost (ford@localhost) by eos.vss.fsi.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA06233; Tue, 31 Aug 1999 11:21:25 -0500 (CDT) X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Tue, 31 Aug 1999 11:21:24 -0500 (CDT) From: Brian Ford X-Sender: ford@eos To: Bruce Korb cc: gcc@gcc.gnu.org Subject: Re: gperf F option? In-Reply-To: <19990831161858.11346.qmail@egcs.cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 31 Aug 1999 korbb@egcs.cygnus.com wrote: > While building gcc (egcs): > > [[...]] > gperf -L C -F ', 0, 0' -p -j1 -i 1 -g -o -t -G -N is_reserved_word \ > -k1,3,$ ../../egcs/gcc/c-parse.gperf >tmp-gperf.h > gperf: invalid option -- F > Usage: gperf [-cCdDef[num]GhHiIjkKlLnNorsStTvWZ7] [input-file] > Try `gperf --help' for more information. > $ gperf --version > GNU gperf 2.7 > http://egcs.cygnus.com/faq.html#gperf -- Brian Ford Software Engineer Vital Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 From gcc-return-9696-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 16:42:41 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17016 invoked by alias); 31 Aug 1999 16:42:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 16983 invoked from network); 31 Aug 1999 16:42:14 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by egcs.cygnus.com with SMTP; 31 Aug 1999 16:42:14 -0000 Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id MAA08792; Tue, 31 Aug 1999 12:42:10 -0400 Received: from marc.watson.ibm.com (marc.watson.ibm.com [9.2.176.11]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id MAA17600; Tue, 31 Aug 1999 12:42:09 -0400 Received: from localhost by marc.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA43770; Tue, 31 Aug 1999 12:42:09 -0400 Message-Id: <9908311642.AA43770@marc.watson.ibm.com> To: "Bruce Korb" Cc: gcc@gcc.gnu.org, gcc-bugs@egcs.cygnus.com, autogen@linuxbox.com Subject: Re: gperf F option? In-Reply-To: Message from korbb@egcs.cygnus.com of "Tue, 31 Aug 1999 09:18:58 PDT." <19990831161858.11346.qmail@egcs.cygnus.com> Date: Tue, 31 Aug 1999 12:42:08 -0400 From: David Edelsohn You are not using a new enough version of gperf. David From gcc-return-9697-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 16:47:11 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 19024 invoked by alias); 31 Aug 1999 16:47:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18995 invoked from network); 31 Aug 1999 16:47:06 -0000 Received: from speedbros.com (HELO speedbros.speedbros.com) (root@216.88.107.9) by egcs.cygnus.com with SMTP; 31 Aug 1999 16:47:06 -0000 Received: from mine (mine@speedbros.com [216.88.107.10] (may be forged)) by speedbros.speedbros.com (8.9.0/8.9.1) with SMTP id KAA01426; Tue, 31 Aug 1999 10:48:34 -0500 From: Dean Wilson To: gcc@gcc.gnu.org Subject: Re: gperf F option? Date: Tue, 31 Aug 1999 11:52:05 -0500 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <19990831161858.11346.qmail@egcs.cygnus.com> In-Reply-To: <19990831161858.11346.qmail@egcs.cygnus.com> Cc: korbb@egcs.cygnus.com MIME-Version: 1.0 Message-Id: <99083111564700.00128@mine> Content-Transfer-Encoding: 8bit On Tue, 31 Aug 1999, you wrote: > While building gcc (egcs): > > [[...]] > ln cccp cpp > gperf -L C -F ', 0, 0' -p -j1 -i 1 -g -o -t -G -N is_reserved_word \ > -k1,3,$ ../../egcs/gcc/c-parse.gperf >tmp-gperf.h > gperf: invalid option -- F > Usage: gperf [-cCdDef[num]GhHiIjkKlLnNorsStTvWZ7] [input-file] > Try `gperf --help' for more information. > make[1]: *** [../../egcs/gcc/c-gperf.h] Error 1 > make[1]: Leaving directory `/home/bkorb/tools/egcs/main/=build/gcc' > make: *** [all-gcc] Error 2 > /home/bkorb/tools/egcs/main/=build > $ gperf --version > GNU gperf 2.7 take look at the faq, there is a patch for gperf in /pub/egcs/infrastructure at sourceware, that deals with this issue. From gcc-return-9698-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 17:03:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 24744 invoked by alias); 31 Aug 1999 17:03:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 24713 invoked from network); 31 Aug 1999 17:03:02 -0000 Received: from mail.provi.de (193.98.9.7) by egcs.cygnus.com with SMTP; 31 Aug 1999 17:03:02 -0000 Received: from kahlert.linux.provi.de ([195.222.239.44] helo=keksy.linux.provi.de) by mail.provi.de with esmtp (Exim 2.12 #1) id 11LrJH-0008Sh-00; Tue, 31 Aug 1999 19:03:03 +0200 Received: (from martin@localhost) by keksy.linux.provi.de (8.8.8/8.8.8) id TAA00532; Tue, 31 Aug 1999 19:06:56 +0200 Message-ID: <19990831190656.A208@keksy.linux.provi.de> Date: Tue, 31 Aug 1999 19:06:56 +0200 From: Martin Kahlert To: Kevin Maguire Cc: egcs@egcs.cygnus.com Subject: Re: g77 performance on ALPHA Reply-To: martin.kahlert@provi.de References: <199908281130.NAA00385@keksy.linux.provi.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: ; from Kevin Maguire on Tue, Aug 31, 1999 at 12:20:28AM +0100 Quoting Kevin Maguire (K.Maguire@dl.ac.uk): > Hi Martin > > Excuse my ignorance but .... > ||(The handcoded asm-daxpy of Mr. Goto gets 378.55 MFlops) > > Where can I get the hnandcoded BLAS? Mr. Goto?? Is this the Compaq > CXML? Is it better? It is better than CXML. Kazushige Goto from Japan spent some time and effort and coded some blas routines in asm. E.g. the ?axpy ?gemm, ?dot routines. The dgemm routine for example get about 950MFlops on an 600MHz 21164 (ev5!). I don't know, how good these routines are for 21264 cpus, but they should be even faster there. The only problem is, i can't reach the URL any more. It used to be http://www.neuro.uni-oldenburg.de/~joe/math but the server refuses any connects, now. > > On my 500MHz Alpha/Linux (ev6) box I get: > > % g77 -O3 blas1.f > % repeat 5 ./a.out > 288.39993 MFlops > 288.450704 MFlops > 288.045032 MFlops > 288.045032 MFlops > 287.640449 MFlops > % fort -O -fast -tune ev6 -arch ev6 -O3 blas1.f > % repeat 5 ./a.out > 393.846153846154 MFlops > 393.846153846154 MFlops > 393.846153846154 MFlops > 393.846153846154 MFlops > 393.846153846154 MFlops > % fort -O -fast -tune ev6 -arch ev6 -O3 blas1-cxml.f -lcxml > % repeat 5 ./a.out > 461.261261261261 MFlops > 460.095352622334 MFlops > 460.224655977789 MFlops > 460.224655977789 MFlops > 462.302419375394 MFlops > % g77 -O3 blas1-cxml.f -lcxml > % repeat 5 ./a.out > 461.261261 MFlops > 460.224782 MFlops > 458.165486 MFlops > 461.261261 MFlops > 461.261261 MFlops Impressive, i think this comes from the out of order capabilities of the 21164. Bye, Martin. -- Your mouse has moved, Windows must be restarted for changes to take affect - restart now? From gcc-return-9699-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 17:12:24 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26676 invoked by alias); 31 Aug 1999 17:12:13 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26659 invoked from network); 31 Aug 1999 17:12:06 -0000 Received: from europe.std.com (199.172.62.20) by egcs.cygnus.com with SMTP; 31 Aug 1999 17:12:05 -0000 Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id NAA16745 for ; Tue, 31 Aug 1999 13:12:02 -0400 (EDT) From: craig@jcb-sc.com Received: from world.std.com (burley@world.std.com [192.74.137.5]) by world.std.com (8.9.3/8.9.3) with ESMTP id NAA28258 for ; Tue, 31 Aug 1999 13:09:00 -0400 (EDT) Received: (qmail 28422 invoked by uid 500); 31 Aug 1999 17:09:44 -0000 Date: 31 Aug 1999 17:09:44 -0000 Message-ID: <19990831170944.28421.qmail@deer> To: martin.kahlert@provi.de CC: K.Maguire@dl.ac.uk, egcs@egcs.cygnus.com cc: craig@jcb-sc.com In-reply-to: <19990831190656.A208@keksy.linux.provi.de> (message from Martin Kahlert on Tue, 31 Aug 1999 19:06:56 +0200) Subject: Re: g77 performance on ALPHA References: <199908281130.NAA00385@keksy.linux.provi.de> <19990831190656.A208@keksy.linux.provi.de> >Impressive, i think this comes from the out of order >capabilities of the 21164. You mean of the 21264, I think? I don't think 21164 has OOO. tq vm, (burley) From gcc-return-9700-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 17:33:30 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30298 invoked by alias); 31 Aug 1999 17:33:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30276 invoked from network); 31 Aug 1999 17:33:15 -0000 Received: from mserv1.dl.ac.uk (root@148.79.160.65) by egcs.cygnus.com with SMTP; 31 Aug 1999 17:33:15 -0000 Received: from tca1.dl.ac.uk (tca1.dl.ac.uk [193.62.112.34]) by mserv1.dl.ac.uk with ESMTP id SAA14623 (8.8.8/5.4[ref postmaster@dl.ac.uk] for dl.ac.uk from K.Maguire@dl.ac.uk); Tue, 31 Aug 1999 18:33:20 +0100 (BST) Received: from localhost (kcm@localhost) by tca1.dl.ac.uk (8.9.3/8.8.7) with ESMTP id SAA01960; Tue, 31 Aug 1999 18:32:37 +0100 Date: Tue, 31 Aug 1999 18:32:37 +0100 (BST) From: Kevin Maguire Reply-To: Kevin Maguire To: Martin Kahlert cc: Kevin Maguire , egcs@egcs.cygnus.com Subject: Re: g77 performance on ALPHA In-Reply-To: <19990831190656.A208@keksy.linux.provi.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Martin On Tue, 31 Aug 1999, Martin Kahlert wrote: ||> Excuse my ignorance but .... ||> ||(The handcoded asm-daxpy of Mr. Goto gets 378.55 MFlops) ||> ||> Where can I get the hnandcoded BLAS? Mr. Goto?? Is this the Compaq ||> CXML? Is it better? ||It is better than CXML. Kazushige Goto from Japan spent some time and effort ||and coded some blas routines in asm. E.g. the ?axpy ?gemm, ?dot routines. ||The dgemm routine for example get about 950MFlops on an 600MHz ||21164 (ev5!). I don't know, how good these routines are for 21264 cpus, ||but they should be even faster there. The only problem is, i can't reach the ||URL any more. It used to be http://www.neuro.uni-oldenburg.de/~joe/math ||but the server refuses any connects, now. I found a more current URL: ftp://www.netstat.ne.jp/pub/Linux/Linux-Alpha-JP/BLAS I can now add to yesterdays results On my 500MHz Alpha/Linux (ev6) box I get: % g77 -O3 blas1.f % repeat 5 ./a.out 288.39993 MFlops 288.450704 MFlops 288.045032 MFlops 288.045032 MFlops 287.640449 MFlops % fort -O -fast -tune ev6 -arch ev6 -O3 blas1.f % repeat 5 ./a.out 393.846153846154 MFlops 393.846153846154 MFlops 393.846153846154 MFlops 393.846153846154 MFlops 393.846153846154 MFlops % fort -O -fast -tune ev6 -arch ev6 -O3 blas1-cxml.f -lcxml % repeat 5 ./a.out 461.261261261261 MFlops 460.095352622334 MFlops 460.224655977789 MFlops 460.224655977789 MFlops 462.302419375394 MFlops % fort -O -fast -tune ev6 -arch ev6 -O3 blas1-cxml.f -lcxml % repeat 5 ./a.out 461.261261 MFlops 460.224782 MFlops 458.165486 MFlops 461.261261 MFlops 461.261261 MFlops ||Impressive, i think this comes from the out of order ||capabilities of the 21164. As has been pointed out I think you mean 21264. % fort -O5 -fast -tune ev6 -arch ev6 blas1-cxml.f ~/AlphaBLAS/axpy-981128/libaxpy.a % repeat 5 ./a.out 504.433498 MFlops 501.960784 MFlops 504.433498 MFlops 500.733571 MFlops 501.960784 MFlops I also have a short F95 code which measures dgemm/dsymm/matmul speed in MFlops. % fort -O5 -fast -tune ev6 -arch ev6 tblas3-95.f90 -lcxml % ./a.out size dsymm dgemm matmul 200 1.0 5.6 1.5713 1.4297 2.5244 654.96 719.84 407.68 8 10000 300 3.0 19.7 3.7578 3.5859 6.4854 692.08 725.20 401.04 6 10000 400 6.0 43.8 6.2500 5.7812 11.7500 656.96 710.24 349.44 4 10000 500 9.0 65.9 6.1172 5.6406 9.9307 655.20 710.56 403.60 2 10000 600 11.0 85.6 5.2266 4.8672 8.6826 662.32 711.28 398.72 1 10000 % fort -O5 -fast -tune ev6 -arch ev6 tblas3-95.f90 ~/AlphaBLAS/gemm/libgemm.a -lcxml % ./a.out size dsymm dgemm matmul 200 1.0 5.4 1.4229 1.2734 2.6484 723.28 808.16 388.56 8 10000 300 3.0 18.8 3.5703 3.3203 6.2979 728.40 783.28 412.96 6 10000 400 5.0 40.1 5.6875 5.1406 10.2285 722.00 798.80 401.44 4 10000 500 8.0 61.1 5.5469 5.0791 9.8232 722.56 789.12 408.00 2 10000 600 10.0 79.8 4.7969 4.3516 8.6836 721.68 795.52 398.64 1 10000 The improvement is dsymm implies that the cxml dsymm calls the Goto dgemm I suppose. Thanks, kevin -- ___________________________________________________ | Kevin Maguire DisCo Support | | CSE CLRC Daresbury Laboratory | | e-mail: K.Maguire@dl.ac.uk | | Tel: 01925 603221 Fax: 01925 603634 | | - - - - - - - | |__ http://www.cse.clrc.ac.uk/Activity/DISCO ___| From gcc-return-9701-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 17:35:09 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 31111 invoked by alias); 31 Aug 1999 17:35:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 31077 invoked from network); 31 Aug 1999 17:35:05 -0000 Received: from unknown (HELO tetto.liafa.jussieu.fr) (espie@132.227.81.252) by egcs.cygnus.com with SMTP; 31 Aug 1999 17:35:05 -0000 Received: (from espie@localhost) by tetto.liafa.jussieu.fr (8.9.3/8.9.1) id TAA13304 for egcs@egcs.cygnus.com; Tue, 31 Aug 1999 19:33:58 +0200 (CEST) Date: Tue, 31 Aug 1999 19:33:58 +0200 From: Marc Espie To: egcs@egcs.cygnus.com Subject: ASM_GENERATE_INTERNAL_LABEL synopsis ? Message-ID: <19990831193358.A25660@tetto.liafa.jussieu.fr> Reply-To: Marc.Espie@liafa.jussieu.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Looking at dwarf2out.c, I believe that ASM_GENERATE_INTERNAL_LABEL and its twins may be currently badly defined. Either they should be able to handle unsigned long as well, in which case the prototype should printf("%lu", (unsigned long) number); or some definitions in dwarf2out.c are broken. In any case, the current state of affairs is dangerous. The type of the number passed to this macro should be documented, or coerced to a proper type so that it doesn't confuse printf. What do you people think ? I can write the patch involved, but it is rather large, as this involve quite a number of files... From gcc-return-9702-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 17:47:57 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 855 invoked by alias); 31 Aug 1999 17:47:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 836 invoked from network); 31 Aug 1999 17:47:46 -0000 Received: from mail.indiciis.com (HELO indiciis.com) (194.74.6.20) by egcs.cygnus.com with SMTP; 31 Aug 1999 17:47:46 -0000 Received: by gateway.indiciis.com id <115201>; Tue, 31 Aug 1999 18:45:27 +0100 Message-Id: <99Aug31.184527bst.115201@gateway.indiciis.com> X-Sender: andrew@indiciis.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Tue, 31 Aug 1999 18:46:29 +0100 To: gcc@gcc.gnu.org From: Andrew Waters Subject: Re: Strange behaviour in C++... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" One paper examining the cost of different implementations of virtual functions is 'Evaluating Virtual Dispatch Mechanisms for C++' by Harini Srinivasan and Peter F. Sweeney A copy of this can be found online at: http://domino.watson.ibm.com/library/CyberDig.nsf/a3807c5b4823c53f85256561006324be/75e04e3da4ce276d85256593007005ea?OpenDocument From gcc-return-9703-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 18:11:04 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5357 invoked by alias); 31 Aug 1999 18:11:03 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5341 invoked from network); 31 Aug 1999 18:11:01 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 31 Aug 1999 18:11:01 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA12270; Tue, 31 Aug 1999 11:11:00 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id LAA10292; Tue, 31 Aug 1999 11:11:00 -0700 (PDT) Date: Tue, 31 Aug 1999 11:11:00 -0700 (PDT) Message-Id: <199908311811.LAA10292@kankakee.wrs.com> To: Marc.Espie@liafa.jussieu.fr, egcs@egcs.cygnus.com Subject: Re: ASM_GENERATE_INTERNAL_LABEL synopsis ? > Date: Tue, 31 Aug 1999 19:33:58 +0200 > From: Marc Espie > Looking at dwarf2out.c, I believe that ASM_GENERATE_INTERNAL_LABEL > and its twins may be currently badly defined. Do you use values beyond 2 billion? If not, why worry about it? If so, can they be squished by the user to be less? If not, how big is the input to the compiler, and how large is the output? I think we want to skip playing with unsigned and go straight to long long if needed, I just question the need. From gcc-return-9704-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 18:53:26 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13330 invoked by alias); 31 Aug 1999 18:53:20 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13313 invoked from network); 31 Aug 1999 18:53:14 -0000 Received: from mail.moene.indiv.nluug.nl (HELO moene.indiv.nluug.nl) (root@195.109.255.217) by egcs.cygnus.com with SMTP; 31 Aug 1999 18:53:14 -0000 Received: from moene.indiv.nluug.nl (toon@localhost [127.0.0.1]) by moene.indiv.nluug.nl (8.8.7/8.8.7) with ESMTP id UAA01013; Tue, 31 Aug 1999 20:51:21 +0200 Message-ID: <37CC2429.57F30F5@moene.indiv.nluug.nl> Date: Tue, 31 Aug 1999 20:51:21 +0200 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: N8TM@aol.com CC: torvalds@transmeta.com, submit-linux-egcs@transmeta.com, gcc@gcc.gnu.org Subject: Re: g77 performance on ALPHA References: <833a759d.24fd2581@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit N8TM@aol.com wrote: > In a message dated 8/30/99 11:55:55 PM EST, torvalds@transmeta.com writes: > > do the proper > > iteration unrolling, testing the loop count just once for "4 or more > > iterations" and then the actual unrolled body would not have any control > > dependencies. > > > > For some reason I thought gcc already did that, but it obviously > > doesn't > That's the difference between "unroll-loops" (if the compiler is > willing) and "unroll-all-loops." Well, I already pointed out that the compiler is "willing" on the ix86 and rth mumbled something about "losing iteration information that the unroller needs" and that specifying -fno-rerun-loop-opt is a work-around. Somehow I missed the blt sandwiches in the "unroll-all-loops" unrolled loop ... Furthermore, reading alpha.md and knowing that Fortran's alias analysis will prove X and Y (and ALPHA) non-overlapping I'd say that g77 should be able to push up all the loads and and down all the stores in the loop. Unfortunately, my DS10 is still not "operational"; hence I cannot easily check this :-( -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html From gcc-return-9705-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 19:27:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21436 invoked by alias); 31 Aug 1999 19:27:20 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21421 invoked from network); 31 Aug 1999 19:27:16 -0000 Received: from mail.provi.de (193.98.9.7) by egcs.cygnus.com with SMTP; 31 Aug 1999 19:27:16 -0000 Received: from kahlert.linux.provi.de ([195.222.239.44] helo=keksy.linux.provi.de) by mail.provi.de with esmtp (Exim 2.12 #1) id 11LtYr-0000hZ-00; Tue, 31 Aug 1999 21:27:17 +0200 Received: (from martin@localhost) by keksy.linux.provi.de (8.8.8/8.8.8) id VAA00930; Tue, 31 Aug 1999 21:31:10 +0200 Message-ID: <19990831213109.A903@keksy.linux.provi.de> Date: Tue, 31 Aug 1999 21:31:09 +0200 From: Martin Kahlert To: Kevin Maguire Cc: egcs@egcs.cygnus.com Subject: Re: g77 performance on ALPHA Reply-To: martin.kahlert@provi.de References: <19990831190656.A208@keksy.linux.provi.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: ; from Kevin Maguire on Tue, Aug 31, 1999 at 06:32:37PM +0100 Quoting Kevin Maguire (K.Maguire@dl.ac.uk): > I found a more current URL: > ftp://www.netstat.ne.jp/pub/Linux/Linux-Alpha-JP/BLAS That's the original ftp space of Mr. Goto, i think. On the neuro-page, there was a rpm with a complete lapack/blas. All other routines were taken from another optimized fortran code (not from netlib). Then there were very fast math routines (written bei Joachim Wesner and asm coded by Mr. Goto). The code was taken from Cray. I think they were called libffm-0.28 or libfastmath or something like that. There was very fast support of sqrt, sin, cos, tan.. and a vector version of sqrt (if you want to sqrt a whole vector). I assume, this is less critical, since the fast math routines were released by Compaq. > ||Impressive, i think this comes from the out of order > ||capabilities of the 21164. > > As has been pointed out I think you mean 21264. Of course, sorry. Unfortunately a 21264 is a bit out of my budget ;-) Bye, Martin. -- Your mouse has moved, Windows must be restarted for changes to take affect - restart now? From gcc-return-9706-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 19:31:16 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23212 invoked by alias); 31 Aug 1999 19:31:10 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23171 invoked from network); 31 Aug 1999 19:31:05 -0000 Received: from d-229.man.ttlc.net (HELO data.ecora.com) (root@208.130.15.229) by egcs.cygnus.com with SMTP; 31 Aug 1999 19:31:05 -0000 Received: from data.ecora.com (IDENT:tudor@data.ecora.com [192.168.0.1]) by data.ecora.com (8.9.3/8.8.7) with SMTP id PAA05543 for ; Tue, 31 Aug 1999 15:30:55 -0400 X-Mailer: 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) (via feedmail 8 I); VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14284.11629.317341.603891@data.ecora.com> Date: Tue, 31 Aug 1999 15:30:53 -0400 (EDT) From: Tudor Hulubei To: gcc@gcc.gnu.org Subject: Memory leaks? Reply-To: Tudor Hulubei Organization: ecora.com Hello, I recently tried to compile a C++ library that the company I'm working for is developing and failed miserably (when optimizing) because of egcs-1.1.2 trying to use more than 670Mb of memory! (I added a 0.5Gb swap partition to no avail). I know about the FAQ entry about memory exhaustion. I attempted to compile the code with the following flags: -D_GNU_SOURCE -W -Wall -ansi -Wwrite-strings -Woverloaded-virtual -Wstrict-prototypes -Wcast-align -Wcast-qual -O3 -finline-functions -fforce-addr -fforce-mem -funroll-loops -fomit-frame-pointer -Wno-return-type -march=pentiumpro -malign-double -malign-loops=2 -malign-functions=2 -malign-jumps=2 I have written a small memory watchdog (for which I can provide source code if anybody is interested) and I use it to count memory leaks in my programs (it uses the malloc hooks provided by glibc). I linked it against cc1plus and got hundreds of memory leaks even when compiling small files like "int main() {}" (this was with gcc-2.95.1). The leaks seem to be mostly from obstack allocations in make_node(). My question is whether or not cc1plus deallocates everything upon exit or leaves it there knowing that the kernel will do it anyway, because in the latter case the leaks reported by my memory watchdog tool are totally useless. I would appreciate any hints. Thank you, Tudor P.S. I'm running RedHat 6.0 (i386) + egcs & gcc-2.95.1. From gcc-return-9707-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 19:38:40 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26144 invoked by alias); 31 Aug 1999 19:38:27 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26066 invoked from network); 31 Aug 1999 19:38:19 -0000 Received: from alina.acomp.usf.edu (131.247.100.28) by egcs.cygnus.com with SMTP; 31 Aug 1999 19:38:19 -0000 Received: from localhost (black@localhost) by alina.acomp.usf.edu (8.8.8+Sun/8.8.8) with ESMTP id PAA00407 for ; Tue, 31 Aug 1999 15:34:41 -0400 (EDT) X-Authentication-Warning: alina.acomp.usf.edu: black owned process doing -bs Date: Tue, 31 Aug 1999 15:34:40 -0400 (EDT) From: James Black X-Sender: black@alina.acomp.usf.edu To: egcs@egcs.cygnus.com Subject: re: failed compilation on Solaris 2.6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I sent a bug report off, but I thought I would mention this here also. I could get the latest version of gcc 2.95 to compile. Following is system info and my configuration, it also had the same error when I had haifa scheduling turned on. ../../egcs-19990830/gcc/fold-const.c: In function `add_double': ../../egcs-19990830/gcc/fold-const.c:248: warning: comparison between signed and unsigned ../../egcs-19990830/gcc/fold-const.c: In function `mul_double': ../../egcs-19990830/gcc/fold-const.c:334: Internal compiler error in `create_reg_dead_note', at haifa-sched.c:4426 ../egcs-19990830/configure\ --with-gcc-version-trigger=/home1/egcs/egcs-19990830/gcc/version.c \ --host=sparc-sun-solaris2.6 --prefix=/usr/local/egcs/ --enable-shared \ --with-gnu-as --with-gnu-ld --enable-threads --with-cpu=ultrasparc \ --enable-version-specific-runtime-libs --norecursion alina# uname -a SunOS alina 5.6 Generic_105181-14 sun4u sparc SUNW,Ultra-1 alina# gcc -v Reading specs from /usr/local/egcs/lib/gcc-lib/sparc-sun-solaris2.6/2.96/specs gcc version 2.96 19990824 (experimental) -- ======================================================================== James Black (Elec Eng Graduate student) e-mail: black@eng.usf.edu http://www.eng.usf.edu/~black/index.html For my public key: finger -l black@eng.usf.edu "A person might be able to play without being creative, but he sure can't be creative without playing" Kurt Hanks & Jay Parry ************************************************************************ From gcc-return-9708-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 19:38:42 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26204 invoked by alias); 31 Aug 1999 19:38:36 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26079 invoked from network); 31 Aug 1999 19:38:21 -0000 Received: from mailgw.chips.ibm.com (192.91.197.8) by egcs.cygnus.com with SMTP; 31 Aug 1999 19:38:21 -0000 Received: from mailrelay.btv.ibm.com (mailrelay.btv.ibm.com [9.66.15.39]) by mailgw.chips.ibm.com (8.8.8/8.8.8) with ESMTP id PAA11006 for ; Tue, 31 Aug 1999 15:38:19 -0400 Received: from btv.ibm.com (flyswatter.btv.ibm.com [9.66.150.42]) by mailrelay.btv.ibm.com (8.8.8/8.8.8) with ESMTP id PAA207360 for ; Tue, 31 Aug 1999 15:37:49 -0400 Message-ID: <37CC2F29.BC582B89@btv.ibm.com> Date: Tue, 31 Aug 1999 15:38:18 -0400 From: Brian Demers Organization: IBM-Burlington X-Mailer: Mozilla 4.5 [en] (X11; U; AIX 4.2) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Re: Alignment option question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think I'm having a similar problem. I'd like to use a struct as an overlay for some data read in from a file. I took a look at the documentation (the section on "Storage Layout" at http://egcs.cygnus.com/onlinedocs/gcc_17.html#SEC201 ), and it seems like the option that I need to pack the fields correctly is in there somewhere, but either I haven't been able to find the right flag or combination of flags yet, or I'm not using the options properly. If anyone can give me a push/shove/kick in the right direction, I'd really appreciate it. Thanks. Brian D. > Yes, please read the manual (*.texi) that we spent considerable time > writting for you. Look for the word pack. Also, if you rearrange the > elements, so the longs are first, it will just work. > > Date: Mon, 30 Aug 1999 21:10:03 -0700 > > To: gcc@gcc.gnu.org > > From: Bill Sheets > > I am having a problem with gcc forcing alignment of short > > and long ints in a structure with version 2.8.1 on Solaris > > on a Sparc system. From gcc-return-9709-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 20:09:51 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3041 invoked by alias); 31 Aug 1999 20:09:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3025 invoked from network); 31 Aug 1999 20:09:42 -0000 Received: from gw-us1.philips.com (@205.167.14.34) by egcs.cygnus.com with SMTP; 31 Aug 1999 20:09:42 -0000 Received: from smtprelay-us1.philips.com (localhost.philips.com [127.0.0.1]) by gw-us1.philips.com with ESMTP id QAA06653 for ; Tue, 31 Aug 1999 16:09:31 -0400 (EDT) (envelope-from Stefan.Thiede@sv.sc.philips.com) Received: from smtprelay-nam1.philips.com(130.140.196.208) by gw-us1.philips.com via mwrap (4.0a) id xma006651; Tue, 31 Aug 99 16:09:31 -0400 Received: from smtphub.sv.sc.philips.com (smtphub.sv.sc.philips.com [130.140.45.86]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA27735 for ; Tue, 31 Aug 1999 16:09:30 -0400 (EDT) Received: from mimir.sv.sc.philips.com (root@mimir.sv.sc.philips.com [161.88.57.11]) by smtphub.sv.sc.philips.com (8.8.5/8.8.5) with ESMTP id NAA12254 for ; Tue, 31 Aug 1999 13:09:29 -0700 (PDT) Received: from sv.sc.philips.com (carbon.sv.sc.philips.com [161.88.56.99]) by mimir.sv.sc.philips.com (8.8.5/8.8.5) with ESMTP id NAA17757 for ; Tue, 31 Aug 1999 13:09:28 -0700 (PDT) Message-ID: <37CC3678.F4D08E0E@sv.sc.philips.com> Date: Tue, 31 Aug 1999 13:09:28 -0700 From: Stefan Thiede Organization: Philips Semiconductors X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: egcs@egcs.cygnus.com Subject: Problems building gcc-2.95.1 on HPUX-10.2 with gcc-2.8.1 and as 2.9.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Could anybody please give me a hint on what's wrong here ? I was able to compile egcs1.1.2 with the same gcc/as combination. Please mail me directly, since I'm not actively following the mailing list. Thanks Stefan PS: Anybody using Qt 2.xx on HP ? I get coredumps on exit and the Trolls seem to think it's gcc and not their code to be blamed :-) gmake[1]: Leaving directory `/tmp_mnt/tools/sandbox/gnu/gcc-2.95.1_hp/gcc/intl' echo "void __foo () {}" > dummy.c ./xgcc -B/tools/sandbox/gnu_hp/hppa2.0-hp-hpux10.20/bin/ -B./ -I/tools/sandbox/gnu_hp/hppa2.0-hp-hpux10.20/include -DIN_GCC -DHAIFA -g -I./include -c dummy.c as: "/var/tmp/ccS6j0AN.s", line 10: error 1052: Directive name not recognized - FILE as: "/var/tmp/ccS6j0AN.s", line 12: error 1052: Directive name not recognized - STABS as: "/var/tmp/ccS6j0AN.s", line 13: error 1052: Directive name not recognized - STABS as: "/var/tmp/ccS6j0AN.s", line 18: error 1052: Directive name not recognized - STABS thor:gcc> as -v GNU assembler version 2.9.1 (hppa1.1-hp-hpux10.20), using BFD version 2.9.1 thor:gcc> gcc -v Reading specs from /cadappl/packages/gnu/1.1/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.8.1/specs gcc version 2.8.1 -- ------------------------------------------------------------------- Stefan Thiede Tel: +1 (650) 335-2544 Windows Systems Group Fax: +1 (650) 335-2514 Philips Semiconductors 811 E. Arques Avenue M/S 42, P.O. Box 3409 email: Stefan.Thiede@sv.sc.philips.com Sunnyvale, CA 94048-3409 seri : thiede@usmtvsc1 From gcc-return-9710-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 20:20:55 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4774 invoked by alias); 31 Aug 1999 20:20:53 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4753 invoked from network); 31 Aug 1999 20:20:50 -0000 Received: from vomit.cygnus.com (HELO upchuck.cygnus.com) (root@208.224.120.148) by egcs.cygnus.com with SMTP; 31 Aug 1999 20:20:50 -0000 Received: from upchuck.cygnus.com (law@localhost [127.0.0.1]) by upchuck.cygnus.com (8.8.7/8.8.7) with ESMTP id OAA19621; Tue, 31 Aug 1999 14:12:14 -0600 X-Mailer: exmh version 2.0.2 To: Stefan Thiede cc: egcs@egcs.cygnus.com Subject: Re: Problems building gcc-2.95.1 on HPUX-10.2 with gcc-2.8.1 and as 2.9.1 Reply-To: law@cygnus.com In-reply-to: Your message of Tue, 31 Aug 1999 13:09:28 PDT. <37CC3678.F4D08E0E@sv.sc.philips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Aug 1999 14:12:13 -0600 Message-ID: <19618.936130333@upchuck.cygnus.com> From: Jeffrey A Law In message <37CC3678.F4D08E0E@sv.sc.philips.com>you write: > Could anybody please give me a hint on what's wrong here ? > I was able to compile egcs1.1.2 with the same gcc/as combination. > > Please mail me directly, since I'm not actively following the mailing > list. You've configured gcc to assume gas is available. But gcc is finding the HP assembler first. Please read the FAQ. It discusses this issue in great detail. jeff From gcc-return-9711-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 20:46:05 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 8494 invoked by alias); 31 Aug 1999 20:45:55 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 8463 invoked from network); 31 Aug 1999 20:45:37 -0000 Received: from server.col.psi.br (200.203.189.130) by egcs.cygnus.com with SMTP; 31 Aug 1999 20:45:37 -0000 Received: (qmail 22426 invoked by alias); 31 Aug 1999 17:47:52 -0000 Received: (qmail 22420 invoked from network); 31 Aug 1999 17:47:51 -0000 Received: from beta.col.psi.br (HELO opensystem.org.br) (root@10.0.0.2) by ana.col.psi.br with SMTP; 31 Aug 1999 17:47:51 -0000 Message-ID: <37CC15F6.6DDE7B2A@opensystem.org.br> Date: Tue, 31 Aug 1999 17:50:46 +0000 From: Leonardo Marques de Souza Reply-To: leo@opensystem.org.br Organization: GU X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-ac2 i586) X-Accept-Language: en MIME-Version: 1.0 CC: gcc@gcc.gnu.org Subject: Binutils 2.9.1.0.2x dont works with gcc-2.95.1... References: <12418.936049010@upchuck.cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Any one can help me??? after a basic install of REdHat-6.0, i compile the binutils with egcs-1.1.2... after that i tryied to compile simple helloworld.c... all fine!!! but after compile and install gcc-2.95.1 , and compile _again_ (yes, i love compilations act!! 8P) binutils.. _all_ programs _stop_ to compile... and a simple program hello.c dont works!!! i got: [root@melissa update]# gcc -o hello hello.c /tmp/ccosLeN3.s: Assembler messages: /tmp/ccosLeN3.s:16: Error: Cannot represent relocation type BFD_RELOC_32 /tmp/ccosLeN3.s:25: Internal error! Assertion failure in tc_gen_reloc at ./config/tc-i386.c line 3502. Please report this bug. the program: ---hello.c----- main() { printf("Hello World!\n"); } ----hello.c----- my procedure: install redhat: (basic instalations) compile binutils: > export CC=gcc > export CFLAGS="-O9 -mpentium" >./configure --prefix=/usr >make >rpm -e binutils-xxxxx >cp binutils/ranlib /usr/bin/ # the binutils installation needed your own ranlib to install!!! >make install test hello.c >gcc -o hello hello.c >./hello Hello World! > After That: compile gcc-2.95.1: >./configure --enable-haifa --enable-threads --enable-shared --enable-cpp --enable-cpplib --prefix=/usr >make bootstrap >make install test hello.c >gcc -o hello hello.c >./hello Hello World! > and bintuils: > export CC=gcc > export CFLAGS="-O9 -march=k6" >./configure --prefix=/usr >make >make install >gcc -o hello hello.c [root@melissa update]# gcc -o hello hello.c /tmp/ccosLeN3.s: Assembler messages: /tmp/ccosLeN3.s:16: Error: Cannot represent relocation type BFD_RELOC_32 /tmp/ccosLeN3.s:25: Internal error! Assertion failure in tc_gen_reloc at ./config/tc-i386.c line 3502. Please report this bug. another programs stop to compile to..(apache, own binutils, anythink...) Regard, T+ Leo From gcc-return-9712-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 21:04:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 12796 invoked by alias); 31 Aug 1999 21:04:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 12779 invoked from network); 31 Aug 1999 21:04:19 -0000 Received: from unknown (HELO tetto.liafa.jussieu.fr) (espie@132.227.81.252) by egcs.cygnus.com with SMTP; 31 Aug 1999 21:04:19 -0000 Received: (from espie@localhost) by tetto.liafa.jussieu.fr (8.9.3/8.9.1) id XAA15509; Tue, 31 Aug 1999 23:02:37 +0200 (CEST) Date: Tue, 31 Aug 1999 23:02:36 +0200 From: Marc Espie To: Mike Stump Cc: Marc.Espie@liafa.jussieu.fr, egcs@egcs.cygnus.com Subject: Re: ASM_GENERATE_INTERNAL_LABEL synopsis ? Message-ID: <19990831230236.A19288@tetto.liafa.jussieu.fr> Reply-To: Marc.Espie@liafa.jussieu.fr References: <199908311811.LAA10292@kankakee.wrs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199908311811.LAA10292@kankakee.wrs.com>; from Mike Stump on Tue, Aug 31, 1999 at 11:11:00AM -0700 On Tue, Aug 31, 1999 at 11:11:00AM -0700, Mike Stump wrote: > > Date: Tue, 31 Aug 1999 19:33:58 +0200 > > From: Marc Espie > > > Looking at dwarf2out.c, I believe that ASM_GENERATE_INTERNAL_LABEL > > and its twins may be currently badly defined. > > Do you use values beyond 2 billion? If not, why worry about it? If > so, can they be squished by the user to be less? If not, how big is > the input to the compiler, and how large is the output? > I think we want to skip playing with unsigned and go straight to long > long if needed, I just question the need. What is not at all funny is that, currently, we get printf("%d", unsigned_long_value); depending on the target endianness, and the way it handles var-adic functions, this may just be the source of obscure bugs in some cross-compilers. I agree that having local labels be unsigned long is a bit silly, but this is definitely not the main point here. From gcc-return-9713-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 21:08:10 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 13855 invoked by alias); 31 Aug 1999 21:08:08 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 13747 invoked from network); 31 Aug 1999 21:06:45 -0000 Received: from unknown (HELO cetus.cygnus.com) (root@206.30.183.128) by egcs.cygnus.com with SMTP; 31 Aug 1999 21:06:45 -0000 Received: by cygnus.com via sendmail from stdin id (Debian Smail3.2.0.102) for gcc@gcc.gnu.org; Tue, 31 Aug 1999 17:03:59 -0400 (EDT) Message-Id: Date: Tue, 31 Aug 1999 17:03:59 -0400 (EDT) From: Gavin Romig-Koch To: Subject: MULTIBYTE_CHARS in c-lex.c and cp/lex.c Bcc: There is a undef at the top of c-lex.c that turns off MULTIBYTE_CHARS if CROSS_COMPILE is set. There is not a similar undef at the top of cp/lex.c. Can anybody shed light on why the difference? Is it because cp/lex.c is always built with gcc, while c-lex.c might be built with some other compiler? -gavin... From gcc-return-9714-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 21:14:28 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15835 invoked by alias); 31 Aug 1999 21:14: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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 15783 invoked from network); 31 Aug 1999 21:14:22 -0000 Received: from mail6.globalserve.net (209.90.128.166) by egcs.cygnus.com with SMTP; 31 Aug 1999 21:14:22 -0000 Received: from smurf (dialin274.hamilton.globalserve.net [209.90.139.83]) by mail6.globalserve.net (8.9.3/8.9.3) with SMTP id RAA18929 for ; Tue, 31 Aug 1999 17:25:52 -0400 (EDT) Message-ID: <000901bef3f4$c6e63ce0$538b5ad1@smurf> From: "ron m" To: Subject: Downloading GCC Date: Tue, 31 Aug 1999 16:41:53 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01BEF3CF.BB55E120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BEF3CF.BB55E120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For some reason the downloads I've gotten from your site at ftp.gnu.org, = (for exapmle the GCC 2.95.1, gzip under Chill distr), have not gunzipped = properly. Whenever I go to expand the files I'm told that there is = only 1 file to expand and am prompted to give a file extension to it. =20 I'm using Winzip 7.0 and have gunzipped things properly in the past. = Please tell me whether this problem is just me, and if so (if you know) = how to correct this. Thanks. ------=_NextPart_000_0004_01BEF3CF.BB55E120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    For some reason the downloads I've = gotten from=20 your site at ftp.gnu.org, (for exapmle the GCC 2.95.1, gzip under Chill = distr),=20 have not gunzipped properly.  Whenever I go to expand the files = I'm =20 told that there is only 1 file to expand and am prompted to give a file=20 extension to it. 
     
    I'm using Winzip 7.0 and have = gunzipped things=20 properly in the past.  Please tell me whether this problem is just = me, and=20 if so (if you know) how to correct this. =20 Thanks.
    ------=_NextPart_000_0004_01BEF3CF.BB55E120-- From gcc-return-9715-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 21:26:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17852 invoked by alias); 31 Aug 1999 21:25:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17757 invoked from network); 31 Aug 1999 21:25:33 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 31 Aug 1999 21:25:33 -0000 Received: from cygnus.com (to-dhcp9.to.cygnus.com [207.34.249.209]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA25704; Tue, 31 Aug 1999 14:25:30 -0700 (PDT) Message-ID: <37CC486D.22EDCFFB@cygnus.com> Date: Tue, 31 Aug 1999 17:26:06 -0400 From: Dave Brolley Organization: Cygnus Solutions Canada Ltd X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: Gavin Romig-Koch CC: gcc@gcc.gnu.org Subject: Re: MULTIBYTE_CHARS in c-lex.c and cp/lex.c References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gavin Romig-Koch wrote: > There is a undef at the top of c-lex.c that turns off MULTIBYTE_CHARS > if CROSS_COMPILE is set. There is not a similar undef at the top > of cp/lex.c. Can anybody shed light on why the difference? > > Is it because cp/lex.c is always built with gcc, while c-lex.c might > be built with some other compiler? The one in c-lex.c should probably be removed. The rationale for it being there is that the compiler can only recognize and convert multibyte characters using information provided by the host locale, which may not make any sense for the target when cross compiling. However, we have support for several pseudo-locales (C-JIS, C-SJIS, C-EUCJP) which could be useful in a cross compiler and other host-locale character sets may also be valid on the target of a cross compiler. So I say, leave it enabled for cross compilers as well. Dave From gcc-return-9716-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 21:30:25 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 18920 invoked by alias); 31 Aug 1999 21:29:54 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 18872 invoked from network); 31 Aug 1999 21:29:36 -0000 Received: from 209-249-66-150.snj0.flashcom.net (HELO ocean.lucon.org) (postfix@209.249.66.150) by egcs.cygnus.com with SMTP; 31 Aug 1999 21:29:36 -0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id C65101B493; Tue, 31 Aug 1999 14:28:52 -0700 (PDT) Subject: binutils 2.9.5.0.10 is released. To: linux-gcc@vger.rutgers.edu (linuxgcc) Date: Tue, 31 Aug 1999 14:28:52 -0700 (PDT) Cc: kjahds@kjahds.com (Kenneth Albanowski), lmfken@lmf.ericsson.se (Kenneth Osterberg), mat@lcs.mit.edu (Mat Hostetter), doughera@lafcol.lafayette.edu (Andy Dougherty), brian@mathworks.com (Brian Bourgault), imp@village.org (Warner Losh), meissner@cygnus.com (Michael Meissner), rfg@monkeys.com (Ron Guilmette), linux-binutils-in@polstra.com (John Polstra), galenh@micron.net (Galen Hazelwood), ralf@informatik.uni-koblenz.de (Ralf Baechle), linas@linas.org (Linas Vepstas), aries@hal2000.terra.vein.hu (Feher Janos), libc-hacker@sourceware.cygnus.com (GNU C Library), egcs@egcs.cygnus.com X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990831212852.C65101B493@ocean.lucon.org> From: hjl@lucon.org (H.J. Lu) This is the beta release of binutils 2.9.5.0.10 for Linux, which is based on binutils 1999 0831 plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.9.5.0.10 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.5.0.10.tar.gz. Source code. 2. binutils-2.9.5.0.8-2.9.5.0.10.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.5.0.10-1.src.rpm. Source RPM. 4. binutils-2.9.5.0.10-1.i386.rpm. X86 inary RPM for RedHat 6.0. 5. binutils-2.9.5.0.10-1.alpha.rpm. Alpha binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.valinux.com/pub/support/hjl/binutils Thanks. H.J. Lu hjl@lucon.org 08/31/99 From gcc-return-9717-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 22:40:56 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 30796 invoked by alias); 31 Aug 1999 22:40:47 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 30771 invoked from network); 31 Aug 1999 22:40:28 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 31 Aug 1999 22:40:27 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA24219; Tue, 31 Aug 1999 15:40:19 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id PAA14172; Tue, 31 Aug 1999 15:40:19 -0700 (PDT) Date: Tue, 31 Aug 1999 15:40:19 -0700 (PDT) Message-Id: <199908312240.PAA14172@kankakee.wrs.com> To: gcc@gcc.gnu.org, tudor.hulubei@data.ecora.com Subject: Re: Memory leaks? > Date: Tue, 31 Aug 1999 15:30:53 -0400 (EDT) > From: Tudor Hulubei > To: gcc@gcc.gnu.org > I recently tried to compile a C++ library that the company I'm > working for is developing and failed miserably (when optimizing) > because of egcs-1.1.2 trying to use more than 670Mb of memory! (I > added a 0.5Gb swap partition to no avail). Don't inline. I think you will find the problem goes away. See my previous postings about this, they culminated in a patch to function_cannot_inline_p in integrate.c with a max_insns = ...; line... here are some unique bits to search for: Thu Jan 7 20:33:19 1999 Mike Stump * integrate.c (function_cannot_inline_p): Don't inline unreasonably large functions, even if we say `inline'. If that doesn't work, try and leave out -Wall. From gcc-return-9718-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 22:48:32 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 32542 invoked by alias); 31 Aug 1999 22:48:17 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 32275 invoked from network); 31 Aug 1999 22:48:04 -0000 Received: from mail.cs.tu-berlin.de (root@130.149.17.13) by egcs.cygnus.com with SMTP; 31 Aug 1999 22:48:04 -0000 Received: from mira.isdn.cs.tu-berlin.de (mira.isdn.cs.tu-berlin.de [130.149.221.146]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id AAA20849; Wed, 1 Sep 1999 00:43:26 +0200 (MET DST) Received: (from martin@localhost) by mira.isdn.cs.tu-berlin.de (8.8.7/8.8.7) id AAA00965; Wed, 1 Sep 1999 00:41:50 +0200 Date: Wed, 1 Sep 1999 00:41:50 +0200 Message-Id: <199908312241.AAA00965@mira.isdn.cs.tu-berlin.de> X-Authentication-Warning: mira.isdn.cs.tu-berlin.de: martin set sender to martin@mira.isdn.cs.tu-berlin.de using -f From: "Martin v. Loewis" To: tudor.hulubei@data.ecora.com CC: gcc@gcc.gnu.org In-reply-to: <14284.11629.317341.603891@data.ecora.com> (message from Tudor Hulubei on Tue, 31 Aug 1999 15:30:53 -0400 (EDT)) Subject: Re: Memory leaks? References: <14284.11629.317341.603891@data.ecora.com> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII > The leaks seem to be mostly from obstack allocations in make_node(). > My question is whether or not cc1plus deallocates everything upon exit > or leaves it there knowing that the kernel will do it anyway, because > in the latter case the leaks reported by my memory watchdog tool are > totally useless. It is the latter. Things on the permanent obstack are never released. I believe there is some obstack diagnosis in gcc itself. Regards, Martin From gcc-return-9719-listarch-gcc=gcc.gnu.org@gcc.gnu.org Tue Aug 31 23:17:43 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 3256 invoked by alias); 31 Aug 1999 23:17:39 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 3212 invoked from network); 31 Aug 1999 23:17:36 -0000 Received: from mail.ultimatech.com (HELO dns.ultimatech.com) (207.135.110.249) by egcs.cygnus.com with SMTP; 31 Aug 1999 23:17:36 -0000 Received: from dnsint.ultimatech.com.ultimatech.com (dnsint [207.135.110.250]) by dns.ultimatech.com (8.8.5/8.8.5) with ESMTP id PAA23620; Tue, 31 Aug 1999 15:01:42 -0700 Received: from iago.ultimatech.com.ultimatech.com by dnsint.ultimatech.com.ultimatech.com (8.8.5) id PAA24120; Tue, 31 Aug 1999 15:56:45 -0700 Received: from iago by iago.ultimatech.com.ultimatech.com (8.9.3) id QAA16727; Tue, 31 Aug 1999 16:16:12 -0700 Message-Id: <199908312316.QAA16727@iago.ultimatech.com.ultimatech.com> To: gcc@gcc.gnu.org cc: yumf@iago.ultimatech.com Subject: pthread_* required on hpux10.20 on C++? Date: Tue, 31 Aug 1999 16:16:12 -0600 From: Marco Manfai Yu Hi, I've downloaded and built gcc 2.95.1 with standard as and ld. When I compile a C++ program the linker complains about missing symbols that start with pthread_. I don't use any threads in my code. nm shows that libgcc.a contains unresolved reference to pthreads. Am I missing something during configure or make? I tried --disable-threads on my configure line but it doesn't seem to do anything. Any pointers or help is greatly appreciated. Thank you, Marco Yu ---------------------------------------------------------------------- The following is my configure line and the C++ source code latte:src/gcc-2.95.1<43%> uname -a HP-UX latte B.10.20 A 9000/785 2001234259 two-user license latte:src/gcc-2.95.1<44%> cat config.status #!/bin/sh # This file was generated automatically by configure. Do not edit. # This directory was configured as follows: ./configure --with-gcc-version-trigger=/tools/sparc-solaris/egcs/src/gcc-2.95.1/gcc/version.c --host=hppa2.0-hp-hpux10.20 --prefix=/tools/sparc-solaris/egcs --exec-prefix=/tools/sparc-solaris/egcs/hppa-hpux10 --enable-version-specific-runtime-libs --disable-threads --norecursion # using "mh-frag" ---------------- Here's my C++ source code. #include int main (int, char**) { unsigned k[] = { 10, 10 }; cerr << k[0] << " " << k[1] << endl; } ---------------- Here's the compile log. latte:~/tmp<48%> g++ -v -g -o foo foo.cc Reading specs from /tools/sparc-solaris/egcs/hppa-hpux10/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.1/specs gcc version 2.95.1 19990816 (release) /tools/sparc-solaris/egcs/hppa-hpux10/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.1/cpp -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -Dhppa -Dhp9000s800 -D__hp9000s800 -Dhp9k8 -DPWB -Dhpux -Dunix -D__hppa__ -D__hp9000s800__ -D__hp9000s800 -D__hp9k8__ -D__PWB__ -D__hpux__ -D__unix__ -D__hppa -D__hp9000s800 -D__hp9k8 -D__PWB -D__hpux -D__unix -Asystem(unix) -Asystem(hpux) -Acpu(hppa) -Amachine(hppa) -D__EXCEPTIONS -g -D__hp9000s700 -D_PA_RISC1_1 -D_HPUX_S OURCE -D_HIUX_SOURCE foo.cc /var/tmp/ccE9pYpv.ii GNU CPP version 2.95.1 19990816 (release) (hppa) #include "..." search starts here: #include <...> search starts here: /tools/sparc-solaris/egcs/hppa-hpux10/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.1/include/g++ /usr/local/include /tools/sparc-solaris/egcs/hppa-hpux10/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.1/../../../../hppa2.0-hp-hpux10.20/include /tools/sparc-solaris/egcs/hppa-hpux10/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.1/include /usr/include End of search list. The following default directories have been omitted from the search path: End of omitted list. /tools/sparc-solaris/egcs/hppa-hpux10/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.1/cc1plus /var/tmp/ccE9pYpv.ii -quiet -dumpbase foo.cc -g -version -o /var/tmp/ccSA8t5T.s cc1plus: warning: -g is only supported when using GAS on this processor, cc1plus: warning: -g option disabled. GNU C++ version 2.95.1 19990816 (release) (hppa2.0-hp-hpux10.20) compiled by GNU C version 2.95.1 19990816 (release). /usr/ccs/bin/as -o /var/tmp/ccmCRm6B.o /var/tmp/ccSA8t5T.s /tools/sparc-solaris/egcs/hppa-hpux10/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.1/collect2 -L/lib/pa1.1 -L/usr/lib/pa1.1 -z -u main -o foo /usr/ccs/lib/crt0.o -L/tools/sparc-solaris/egcs/hppa-hpux10/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.1 -L/usr/ccs/bin -L/usr/ccs/lib -L/tools/sparc-solaris/egcs/hppa-hpux10/lib /var/tmp/ccmCRm6B.o -lstdc++ -lm -lgcc -lc -lgcc /usr/ccs/bin/ld: Unsatisfied symbols: pthread_once (code) pthread_setspecific (code) pthread_getspecific (code) pthread_keycreate (code) collect2: ld returned 1 exit status From gcc-return-9720-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 00:03:17 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 9769 invoked by alias); 1 Sep 1999 00:03:15 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 9753 invoked from network); 1 Sep 1999 00:03:12 -0000 Received: from d-229.man.ttlc.net (HELO data.ecora.com) (root@208.130.15.229) by egcs.cygnus.com with SMTP; 1 Sep 1999 00:03:12 -0000 Received: from data.ecora.com (IDENT:tudor@data.ecora.com [192.168.0.1]) by data.ecora.com (8.9.3/8.8.7) with SMTP id UAA17181; Tue, 31 Aug 1999 20:00:18 -0400 X-Mailer: 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) (via feedmail 8 I); VM 6.71 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14284.27793.301110.559056@data.ecora.com> Date: Tue, 31 Aug 1999 20:00:17 -0400 (EDT) From: Tudor Hulubei To: Mike Stump Cc: gcc@gcc.gnu.org Subject: Re: Memory leaks? References: <199908312240.PAA14172@kankakee.wrs.com> Reply-To: Tudor Hulubei Organization: ecora.com On Tuesday, 31 August 1999, Mike Stump wrote: > Don't inline. I think you will find the problem goes away. You mean removing -finline-functions? It didn't work. > If that doesn't work, try and leave out -Wall. That didn't work either. I removed all the flags except -O3. That alone made cc1plus go to almost 600Mb, when I decided to stop it. Same with -O2. The only thing that kept egcs-1.1.2 under 200Mb was going down to -O1. Compilation time was around 12min (Pentium III/450MHz, 256Mb RAM), but hey, at least it worked :-). Actually, c++ -O1 + all the other options and warnings enabled remained around 200Mb. Tudor From gcc-return-9721-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 01:00:27 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 17450 invoked by alias); 1 Sep 1999 01:00:25 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17425 invoked from network); 1 Sep 1999 01:00:21 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 1 Sep 1999 01:00:21 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id RAA10845; Tue, 31 Aug 1999 17:58:17 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id RAA07427; Tue, 31 Aug 1999 17:58:16 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id RAA14680; Tue, 31 Aug 1999 17:58:15 -0700 Message-Id: <199909010058.RAA14680@atrus.synopsys.com> Subject: Re: Memory leaks? To: tudor.hulubei@data.ecora.com Date: Tue, 31 Aug 99 17:58:15 PDT Cc: mrs@wrs.com, gcc@gcc.gnu.org In-Reply-To: <14284.27793.301110.559056@data.ecora.com>; from "Tudor Hulubei" at Aug 31, 99 8:00 pm X-Mailer: ELM [version 2.3 PL11] > On Tuesday, 31 August 1999, Mike Stump wrote: > > Don't inline. I think you will find the problem goes away. > > You mean removing -finline-functions? It didn't work. Actually -O3 turns on inlining even of functions that aren't marked inline. > I removed all the flags except -O3. That alone made cc1plus go to > almost 600Mb, when I decided to stop it. Same with -O2. I don't know why -O2 would be so large. > The only thing that kept egcs-1.1.2 under 200Mb was going down to -O1. > Compilation time was around 12min (Pentium III/450MHz, 256Mb RAM), but > hey, at least it worked :-). Can you see if 2.95 or 2.95.1 is better? From gcc-return-9722-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 01:06:20 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 20378 invoked by alias); 1 Sep 1999 01:06:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 20363 invoked from network); 1 Sep 1999 01:06:17 -0000 Received: from dns.cygnus.co.uk (HELO pasanda.cygnus.co.uk) (194.130.39.3) by egcs.cygnus.com with SMTP; 1 Sep 1999 01:06:17 -0000 Received: (qmail 14961 invoked by alias); 1 Sep 1999 01:06:14 -0000 Received: (qmail 14945 invoked from network); 1 Sep 1999 01:06:13 -0000 Received: from phal.cygnus.co.uk (root@194.130.39.5) by dns.cygnus.co.uk with SMTP; 1 Sep 1999 01:06:13 -0000 Received: (from amylaar@localhost) by phal.cygnus.co.uk (8.9.3/8.9.3) id CAA29389; Wed, 1 Sep 1999 02:05:07 +0100 From: Joern Rennecke Message-Id: <199909010105.CAA29389@phal.cygnus.co.uk> Subject: Re: Memory leaks? In-Reply-To: <199909010058.RAA14680@atrus.synopsys.com> from Joe Buck at "Aug 31, 1999 5:58:15 pm" To: jbuck@synopsys.COM (Joe Buck) Date: Wed, 1 Sep 1999 02:05:07 +0100 (BST) Cc: tudor.hulubei@data.ecora.com, mrs@wrs.com, gcc@gcc.gnu.org X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > On Tuesday, 31 August 1999, Mike Stump wrote: > > > Don't inline. I think you will find the problem goes away. > > > > You mean removing -finline-functions? It didn't work. > > Actually -O3 turns on inlining even of functions that aren't marked > inline. > > > I removed all the flags except -O3. That alone made cc1plus go to > > almost 600Mb, when I decided to stop it. Same with -O2. > > I don't know why -O2 would be so large. maybe it's -fcse-follows-jumps -fcse-skip-blocks ? These are enabled by default by -O2. You can disable them with the corresponding -fno- options. From gcc-return-9723-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 01:09:59 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 21372 invoked by alias); 1 Sep 1999 01:09:54 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 21351 invoked from network); 1 Sep 1999 01:09:45 -0000 Received: from unknown-1-11.wrs.com (HELO mail.wrs.com) (147.11.1.11) by egcs.cygnus.com with SMTP; 1 Sep 1999 01:09:45 -0000 Received: from kankakee.wrs.com (kankakee.wrs.com [147.11.37.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA16422; Tue, 31 Aug 1999 18:09:29 -0700 (PDT) From: Mike Stump Received: (from mrs@localhost) by kankakee.wrs.com (8.9.1/8.9.0) id SAA17893; Tue, 31 Aug 1999 18:09:28 -0700 (PDT) Date: Tue, 31 Aug 1999 18:09:28 -0700 (PDT) Message-Id: <199909010109.SAA17893@kankakee.wrs.com> To: tudor.hulubei@data.ecora.com Subject: Re: Memory leaks? Cc: gcc@gcc.gnu.org > Date: Tue, 31 Aug 1999 20:00:17 -0400 (EDT) > From: Tudor Hulubei > To: Mike Stump > Cc: gcc@gcc.gnu.org > On Tuesday, 31 August 1999, Mike Stump wrote: > > Don't inline. I think you will find the problem goes away. > You mean removing -finline-functions? No. -fno-inline and -fno-inline-functions or some such spelling, see the manual. From gcc-return-9724-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 01:30:00 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 23178 invoked by alias); 1 Sep 1999 01:29:58 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 23146 invoked from network); 1 Sep 1999 01:29:54 -0000 Received: from lsmls02.we.mediaone.net (24.130.1.15) by egcs.cygnus.com with SMTP; 1 Sep 1999 01:29:54 -0000 Received: from alumni.caltech.edu (we-24-130-78-149.we.mediaone.net [24.130.78.149]) by lsmls02.we.mediaone.net (8.8.7/8.8.7) with ESMTP id SAA14090; Tue, 31 Aug 1999 18:29:46 -0700 (PDT) Message-ID: <37CC822E.C5674CD8@alumni.caltech.edu> Date: Tue, 31 Aug 1999 18:32:30 -0700 From: Dan Kegel X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-initio i586) X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org CC: slouken@devolution.com Subject: Regarding anonymous unions, etc. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I hear the GCC team is soliciting input as to how important Microsoft C++ extensions like anonymous unions, etc. are. I and the folks at Lokigames.com would dearly love to be able to port games from Win32 to Linux more easily. This is complicated by all the Microsoft-isms that won't compile under gcc. The more source code from the Windows world you can compile under gcc, the better, in my book. Thanks, and thanks for a great compiler, Dan -- (The above is my opinion alone, and not that of my employer) From gcc-return-9725-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 01:49:53 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26881 invoked by alias); 1 Sep 1999 01:49:50 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26851 invoked from network); 1 Sep 1999 01:49:45 -0000 Received: from imo-d08.mx.aol.com (205.188.157.40) by egcs.cygnus.com with SMTP; 1 Sep 1999 01:49:45 -0000 Received: from N8TM@aol.com by imo-d08.mx.aol.com (mail_out_v22.4.) id pGSZHxQPR_ (4187); Tue, 31 Aug 1999 21:45:14 -0400 (EDT) From: N8TM@aol.com Message-ID: <13e9a33d.24fddf2a@aol.com> Date: Tue, 31 Aug 1999 21:45:14 EDT Subject: Re: g77 performance on ALPHA To: toon@moene.indiv.nluug.nl CC: torvalds@transmeta.com, submit-linux-egcs@transmeta.com, gcc@gcc.gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows sub 238 In a message dated 8/31/99 1:53:21 PM EST, toon@moene.indiv.nluug.nl writes: > I'd say that g77 should > be able to push up all the loads and and down all the stores in the > loop. It would need to allocate a different group of registers for each iteration of the loop. This would be a big advantage on some of the processors which don't remap registers, and maybe on those which seem to take extra time to move loads past stores. I've been assuming that the trend is toward CPU's which don't depend so much on the compiler. Tim From gcc-return-9726-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 01:52:19 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 27775 invoked by alias); 1 Sep 1999 01:52:18 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 27757 invoked from network); 1 Sep 1999 01:52:16 -0000 Received: from hamachi.synopsys.com (204.176.20.26) by egcs.cygnus.com with SMTP; 1 Sep 1999 01:52:16 -0000 Received: from javelin.synopsys.com (javelin.synopsys.com [146.225.100.38]) by hamachi.synopsys.com (8.8.8/8.8.8) with ESMTP id SAA13872; Tue, 31 Aug 1999 18:51:17 -0700 (PDT) Received: from atrus.synopsys.com (atrus [146.225.121.23]) by javelin.synopsys.com (8.8.8/8.8.8) with SMTP id SAA14612; Tue, 31 Aug 1999 18:51:17 -0700 (PDT) From: Joe Buck Received: by atrus.synopsys.com (SMI-8.6/SNPS-Sol2) id SAA18243; Tue, 31 Aug 1999 18:51:16 -0700 Message-Id: <199909010151.SAA18243@atrus.synopsys.com> Subject: Re: Regarding anonymous unions, etc. To: dank@alumni.caltech.edu (Dan Kegel) Date: Tue, 31 Aug 99 18:51:16 PDT Cc: gcc@gcc.gnu.org, slouken@devolution.com In-Reply-To: <37CC822E.C5674CD8@alumni.caltech.edu>; from "Dan Kegel" at Aug 31, 99 6:32 pm X-Mailer: ELM [version 2.3 PL11] > I hear the GCC team is soliciting input as to how important > Microsoft C++ extensions like anonymous unions, etc. are. Anonymous unions are standard C++ and are supported by GCC. However, MFC does use some non-standard features of MSVC. From gcc-return-9727-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 02:44:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 700 invoked by alias); 1 Sep 1999 02:44:22 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 684 invoked from network); 1 Sep 1999 02:44:17 -0000 Received: from 206-58-251-131.callatg.com (HELO roboto.devolution.com) (root@206.58.251.131) by egcs.cygnus.com with SMTP; 1 Sep 1999 02:44:17 -0000 Received: from slouken by roboto.devolution.com with local (Exim 3.01 #1) id 11M0O8-0003Ti-00; Tue, 31 Aug 1999 19:44:40 -0700 To: Dan Kegel Cc: gcc@gcc.gnu.org, slouken@devolution.com Subject: Re: Regarding anonymous unions, etc. X-Mailer: My Mailer 1.5 Message-Id: From: Sam Lantinga Date: Tue, 31 Aug 1999 19:44:40 -0700 > I hear the GCC team is soliciting input as to how important > Microsoft C++ extensions like anonymous unions, etc. are. > I and the folks at Lokigames.com would dearly love to be able to > port games from Win32 to Linux more easily. This is > complicated by all the Microsoft-isms that won't compile > under gcc. The more source code from the Windows world > you can compile under gcc, the better, in my book. FYI, the new patches from Mumit Khan, which appear to be integrated into the latest CVS version of gcc/egcs, solve many of our problems with anonymous structures and so forth. Kudos to everyone who has been working on GCC. :) -Sam Lantinga (slouken@devolution.com) Lead Programmer, Loki Entertainment Software -- "Any sufficiently advanced bug is indistinguishable from a feature" -- Rich Kulawiec From gcc-return-9728-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 03:02:33 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 4016 invoked by alias); 1 Sep 1999 03:02:28 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 4000 invoked from network); 1 Sep 1999 03:02:21 -0000 Received: from lsmls02.we.mediaone.net (24.130.1.15) by egcs.cygnus.com with SMTP; 1 Sep 1999 03:02:21 -0000 Received: from alumni.caltech.edu (we-24-130-78-149.we.mediaone.net [24.130.78.149]) by lsmls02.we.mediaone.net (8.8.7/8.8.7) with ESMTP id UAA19327; Tue, 31 Aug 1999 20:02:14 -0700 (PDT) Message-ID: <37CC97DA.89E50B3B@alumni.caltech.edu> Date: Tue, 31 Aug 1999 20:04:58 -0700 From: Dan Kegel X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-initio i586) X-Accept-Language: en MIME-Version: 1.0 To: Joe Buck CC: gcc@gcc.gnu.org, slouken@devolution.com Subject: Re: Regarding anonymous unions, etc. References: <199909010151.SAA18243@atrus.synopsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joe Buck wrote: > > > I hear the GCC team is soliciting input as to how important > > Microsoft C++ extensions like anonymous unions, etc. are. > > Anonymous unions are standard C++ and are supported by GCC. However, MFC > does use some non-standard features of MSVC. I'm referring to C, not C++. GCC still refuses to accept anonymous unions in C programs. Visual C accepts them happily. It's not acceptable to compile the C programs as C++. If you can tell me what compiler option to give gcc to get it to accept anonymous unions in C, I'll gladly eat my hat. Thanks, Dan -- (The above is my opinion alone, and not that of my employer) From gcc-return-9729-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 03:14:14 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 5736 invoked by alias); 1 Sep 1999 03:13:56 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5708 invoked from network); 1 Sep 1999 03:13:46 -0000 Received: from thor.xraylith.wisc.edu (198.150.6.11) by egcs.cygnus.com with SMTP; 1 Sep 1999 03:13:45 -0000 Received: from mercury.xraylith.wisc.edu (mercury.xraylith.wisc.edu [128.104.182.221]) by thor.xraylith.wisc.edu (8.9.1a/8.9.1) with ESMTP id WAA04930; Tue, 31 Aug 1999 22:13:42 -0500 Received: from mercury.xraylith.wisc.edu (localhost [127.0.0.1]) by mercury.xraylith.wisc.edu (8.8.7/8.8.7) with ESMTP id WAA18456; Tue, 31 Aug 1999 22:13:08 -0500 Message-Id: <199909010313.WAA18456@mercury.xraylith.wisc.edu> To: Sam Lantinga cc: Dan Kegel , gcc@gcc.gnu.org Subject: Re: Regarding anonymous unions, etc. In-Reply-To: Your message of "Tue, 31 Aug 1999 19:44:40 PDT." Date: Tue, 31 Aug 1999 22:13:08 -0500 From: Mumit Khan Sam Lantinga writes: > > FYI, the new patches from Mumit Khan, which appear to be integrated > into the latest CVS version of gcc/egcs, solve many of our problems > with anonymous structures and so forth. > If you're referring to C++ anon aggregates, it's Jason's and it has been in the "mainline" for a while now, though not in the release branch. If you're referring to C anon aggregates, my patch is certainly not integrated; in fact, I don't believe maintainers have yet looked at it, and I have yet to see any feedback (other than Richard Henderson's initial "Yuk!" reaction to one of the "features" ;-) I've incorporated both of these in the gcc-2.95 binaries I distribute for windows32 however, and it's easy enough to get these out of my patchset available from: ftp://ftp.xraylith.wisc.edu/~khan/software/gnu-win32/cygwin/gcc-2.95/patches/ The patches of interest are: C anon aggregates: gcc-2.95-anon-struct-union.diff ....... Anonymous structs/unions in C. C++ anon structs: gcc-2.95-c++-tidy.diff ................ Jason's C++ "tidying" patch. Prereq for all other C++ patches. gcc-2.95-c++-anon-struct.diff ....... Anonymous structs in C++. gcc-2.95-c++-anon-struct2.diff ....... small tweak. As usual, unsupported in every way imaginable. Regards, Mumit From gcc-return-9730-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 04:17:44 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 11607 invoked by alias); 1 Sep 1999 04:17:35 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 11591 invoked from network); 1 Sep 1999 04:17:32 -0000 Received: from speedbros.com (HELO speedbros.speedbros.com) (root@216.88.107.9) by egcs.cygnus.com with SMTP; 1 Sep 1999 04:17:32 -0000 Received: from mine (mine@speedbros.com [216.88.107.10] (may be forged)) by speedbros.speedbros.com (8.9.0/8.9.1) with SMTP id WAA02193; Tue, 31 Aug 1999 22:18:12 -0500 From: Dean Wilson To: "ron m" Subject: Re: Downloading GCC Date: Tue, 31 Aug 1999 23:23:14 -0500 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <000901bef3f4$c6e63ce0$538b5ad1@smurf> In-Reply-To: <000901bef3f4$c6e63ce0$538b5ad1@smurf> Cc: gcc@gcc.gnu.org MIME-Version: 1.0 Message-Id: <99083123264700.00125@mine> Content-Transfer-Encoding: 8bit On Tue, 31 Aug 1999, you wrote: > > For some reason the downloads I've gotten from your site at ftp.gnu.org, (for exapmle the GCC 2.95.1, gzip under Chill distr), have not gunzipped properly. Whenever I go to expand the files I'm told that there is only 1 file to expand and am prompted to give a file extension to it. > > I'm using Winzip 7.0 and have gunzipped things properly in the past. Please tell me whether this problem is just me, and if so (if you know) how to correct this. Thanks. > ---------------------------------------- Content-Type: text/html; name="unnamed" Content-Transfer-Encoding: quoted-printable Content-Description: ---------------------------------------- the problem is windows doesnt understand more than one . in a file name tell it the extension is tar and then it will want to decompress the tar ball, hope this helps Dean From gcc-return-9731-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 04:52:21 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 15009 invoked by alias); 1 Sep 1999 04:52:19 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 14925 invoked from network); 1 Sep 1999 04:52:18 -0000 Received: from runyon.cygnus.com (HELO cygnus.com) (205.180.230.5) by egcs.cygnus.com with SMTP; 1 Sep 1999 04:52:18 -0000 Received: from bcpl.cygnus.com (bcpl.cygnus.com [205.180.230.59]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id VAA20142; Tue, 31 Aug 1999 21:52:17 -0700 (PDT) Received: (rth@localhost) by bcpl.cygnus.com (8.8.7/8.6.4) id VAA19002; Tue, 31 Aug 1999 21:52:16 -0700 Message-ID: <19990831215216.B18990@cygnus.com> Date: Tue, 31 Aug 1999 21:52:16 -0700 From: Richard Henderson To: Andreas Schwab , Matthias Klose Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: mainline shared object name for libstdc++ References: <14282.47484.47646.169269@bolero> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: ; from Andreas Schwab on Tue, Aug 31, 1999 at 10:13:35AM +0200 On Tue, Aug 31, 1999 at 10:13:35AM +0200, Andreas Schwab wrote: > 1999-08-31 Andreas Schwab > > * configure.in: Move *-*-gnu* pattern below *-*-linux*. Ok. r~ From gcc-return-9732-listarch-gcc=gcc.gnu.org@gcc.gnu.org Wed Sep 01 06:20:18 1999 Return-Path: Delivered-To: listarch-gcc@gcc.gnu.org Received: (qmail 26425 invoked by alias); 1 Sep 1999 06:20:16 -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 Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 26364 invoked from network); 1 Sep 1999 06:20:03 -0000 Received: from scooter.gcal.ac.uk (193.62.224.211) by egcs.cygnus.com with SMTP; 1 Sep 1999 06:20:03 -0000 Received: from atlas.gcal.ac.uk (atlas.) [193.62.225.11] by scooter.gcal.ac.uk ; Wed, 1 Sep 1999 07:18:45 +0100 Received: from localhost by atlas. (SMI-8.6/SMI-SVR4) id HAA25729; Wed, 1 Sep 1999 07:17:25 +0100 Date: Wed, 1 Sep 1999 07:17:25 +0100 To: fuezoma74@bio.fiocruz.br From: fuezoma74@bio.fiocruz.br (oikojus) Comments: Authenticated sender is Subject: -> ReActive - deadline before Sept. 13 Message-Id: <199908314215WAA4929@rescauyers.gcal.ac.uk> To be removed - email us at bene45@bigfoot.com and just tell us. Due to a bill in the Senate (see below) the health supplement ReActive is in jeapordy of becoming unavailable for sale on Sept 13th. This may be your last chance to purchase. Please contact your Representatives and urge them to vote against this insane bill. Please do not sit idly by while yet another valuable medicine is taken from us in the name of "protecting" us! ReActive is a very popular product that is a precursor to GHB and Human Growth Hormone. As such it has been shown to aid muscle building and athletic performance, reduce anxiety stress and depression, have the anti-aging properties associated with Hgh, be a prosexual to both men and women in moderate doses, and in higher doses promote deep restful sleep. Our prices are as follows: Bottle of ReActive - Contains over 40 servings $85.00 Wholesale as low as $35 per bottle. For 10 cases or more call 503-296-2242 for pricing. Order online at www.thewebmastersclub.com/reactive Please read our testimonials page at www.thewebmastersclub.com/reactive/testimonials.htm to find out what out what our customers have said about the effects of this product. A few of many endorsements from our customers: James, I am writing to you to say that I have used Reactive and I have enjoyed the product immensely. I have been using this products since last fall and I have truly gound that it works. With it I have reduced my stress levels from work, I have enjoyed better sleep with a feeling of recovery upon waking, and my mood has improved when I use the product. Also these products have helped my recovery from working out in the gym. I will continue to use this product as long as it is made available. Thanks, Jason _________________________________________________________ James, I would love to give you a testimonial on reactive. I have always been a chronic insomniac, and I've tried every single type of sleeping aid. Either it wouldn't work or it would leave me groggy and tired the next day, and I would be knocked out for ten hours of unsatisfactory, dreamless sleep. Then I would build a tolerance to it and it would cease to work. Reactive worked instantly, and I would wake up well rested, alert, and evn more energetic and positive than I've ever felt. Much to my delight and surprise, I also found that my memory improved, which really helped me at school, and my sex drive, which had been dormant for a few months now due to stress, just went through the roof. My boyfriend finds it hard to keep up with me...pardon the pun. The only thing is that I only sleep for a few hours, not the traditional 8, but I also found that with reactive, you don't need as much sleep. C. Purdue - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dear sir, I want to tell you how pleased I am with your product "ReActive." I am a parish pries with a large congregation which means I must work very long hours. I also used to suffer from sever leg cramps that would keep me awake for hours. Since I have begun using ReActive according to the label directions, I go to sleep quickly, sleep soundly without any leg cramps and wake up earlier, feeling better than I have ever felt before. In short, IT WORKS FOR ME! It has improved my quality of life by a huge amount. Thank you for marketing this product in such a convenient way. Sincerely yours, Fr. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ..And I have spoken to Dr. Ward Dean and Steven Wm. Fowkes (suthors of GHB The Natural Mood Enhancer) and they have said very positive things about GHB precursors. Dr. Ward Dean said that there have been two year toxicology studies where animals were given massive doses of gamma-butyrolactone and it normalized ekg's, shrunk tumors, and suppressed ethanol intake. He said to me "That's good stuff." Steven Fowkes has said however that for every one study of GBL there are one hundred GHB studies and he is an expert in the field of organic chemistry so I believe he knows what he is talking about. I have several articles of the newsletter he publishes that explain the chemical reactions that go on inside the body when one consumes GBL and other precursors... anon from Florida note : GBL, also know as 2(3h) Furanone Di-hydro is the active ingredient in ReActive - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Visit www.thewebmastersclub.com/reactive/bill.htm for information on the bill that would outlaw GHB and ban the sale of Reactive (GBL) To find out who your representative is, look here: http://www.senate.gov/ %

    GCC can not find GNU as/GNU ld