From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28717 invoked by alias); 13 Nov 2002 17:29:33 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 28696 invoked by uid 61); 13 Nov 2002 17:29:31 -0000 Date: Tue, 19 Nov 2002 18:37:00 -0000 Message-ID: <20021113172931.28695.qmail@sources.redhat.com> To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, mengel@fnal.gov, nobody@gcc.gnu.org From: bangerth@dealii.org Reply-To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, mengel@fnal.gov, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: c++/8549: --pedantic-errors problems on RedHat 6.1 X-SW-Source: 2002-11/txt/msg00618.txt.bz2 List-Id: Synopsis: --pedantic-errors problems on RedHat 6.1 State-Changed-From-To: feedback->analyzed State-Changed-By: bangerth State-Changed-When: Wed Nov 13 09:29:30 2002 State-Changed-Why: The problem boils down to the following: in cmath, the isgreaterequal (and other) macros are used, of which the definition has changed between kernels 2.2 and 2.4. They are defined in /usr/include/bits/mathinline.h. The following snippet shows that: -------------------------------------- // code from /usr/include/bits/mathinline.h #if 1 // from kernel 2.2 # define isgreaterequal(x, y) \ ({ register char __result; \ __asm__ ("fucomip %%st(1), %%st; setae %%al" \ : "=a" (__result) : "u" (y), "t" (x) : "cc", "st"); \ __result; }) #else // from kernel 2.4 # define isgreaterequal(x, y) __builtin_isgreaterequal (x, y) #endif int main () { isgreaterequal(1.,2.); }; --------------------------------------- If compiled as is, I get tmp/g> /home/bangerth/bin/gcc-3.2.1-pre/bin/c++ -c -O2 --pedantic-errors foo2.cc foo2.cc: In function `int main()': foo2.cc:14: ISO C++ forbids braced-groups within expressions If I change the #if 1 to #if 0 to enable the code that is in the 2.4 kernel series, I get no errors. This is the behavior of all gccs since 3.0, but also with 2.95! So I think, the whole thing is attributable to the following: Somewhen an extension in gcc was deprecated and the kernel folks changed their header files accordingly.I think the only way to make newer gccs work on these old systems would be to fixinclude the respective header files, but I doubt someone would like to put much energy in backporting gcc to such old systems. What do we do with this report then? Regards Wolfgang http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8549