This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC's statement expression extension
- To: wilson at cygnus dot com
- Subject: Re: GCC's statement expression extension
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Sun, 30 Jul 00 07:02:51 EDT
- Cc: gcc at gcc dot gnu dot org
From wilson@cygnus.com Fri Jul 28 00:24:22 2000
Received: from alpha2.ultra.nyu.edu by vlsi1.ultra.nyu.edu (4.1/1.34)
id AA18487; Fri, 28 Jul 00 00:24:22 EDT
Received: from cygnus.com (runyon.cygnus.com [205.180.230.5])
by alpha2.ultra.nyu.edu (8.9.3/8.9.3) with ESMTP id AAA31914
for <kenner@vlsi1.ultra.nyu.edu>; Fri, 28 Jul 2000 00:02:44 -0400 (EDT)
Received: from wilson.cygnus.com (wilson.cygnus.com [205.180.230.158])
by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id VAA00201;
Thu, 27 Jul 2000 21:11:14 -0700 (PDT)
From: Jim Wilson <wilson@cygnus.com>
Received: (wilson@localhost) by wilson.cygnus.com (8.9.3/8.6.4) id VAA21071; Thu, 27 Jul 2000 21:11:32 -0700
Date: Thu, 27 Jul 2000 21:11:32 -0700
Message-Id: <200007280411.VAA21071@wilson.cygnus.com>
To: kenner@vlsi1.ultra.nyu.edu
Subject: Re: GCC's statement expression extension
Newsgroups: cygnus.egcs
In-Reply-To: <10007280259.AA18359@vlsi1.ultra.nyu.edu>
Cc: gcc@gcc.gnu.org
Status: RO
In article <10007280259.AA18359@vlsi1.ultra.nyu.edu> you write:
> I suspect it is the obstacks use of ({ ... }) and ?: omitting the
> middle argument in gcc 1.35.
>
>Nope. It's an error in bc-typecd.def. Something about a float being
>promoted to double.
It is SPEC92 that contains gcc 1.35, and SPEC92 was obsoleted 5 years ago
when SPEC95 came out. Anyone who cares about SPEC only cares about SPEC2000
now. SPEC95 had gcc 2.5.3. I haven't looked at SPEC2000 yet, but I would
be surprised if it didn't have at least gcc 2.7.2.
By the way, it is SPEC95 that has the bc-typecd.def problem, not SPEC92.
The erroneous code (and yes, it is invalid code) appears within a
#ifdef __GNUC__, so it is only gcc that could possibly fail to compile this
program. And this isn't the only problem with this old code. It isn't
64-bit clean either. I had to fix several bugs to get it working on an
ia64-linux machine. None of these problems justify changing how we
develop gcc.
Jim