From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19317 invoked by alias); 3 Aug 2009 13:52:51 -0000 Received: (qmail 19307 invoked by uid 22791); 3 Aug 2009 13:52:50 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com) (80.70.172.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Aug 2009 13:52:44 +0000 X-SBRSScore: None Received: from abgze77e.fsc.net ([172.25.138.143]) by dgate20u.abg.fsc.net with ESMTP/TLS/RC4-MD5; 03 Aug 2009 15:53:17 +0200 Received: from ABGEX70E.FSC.NET ([172.25.138.140]) by abgze77e.FSC.NET ([172.25.138.143]) with mapi; Mon, 3 Aug 2009 15:52:40 +0200 From: "Unruh, Erwin" To: GCC mailing list Date: Mon, 03 Aug 2009 13:52:00 -0000 Subject: order of -D and -U is significant Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-08/txt/msg00031.txt.bz2 In current gcc the order of options -D and -U is significant. The Single Un= ix(r) Specification explicitly specifies that the order should not matter for the= c89=20 command. It reads (cited from version 2, which is ten years old): -D name[=3Dvalue] Define name as if by a C-language #define directive. If no =3Dvalue is give= n, a value of 1 will be used. The -D option has lower precedence than the -U option. That is, if name is used in both a -U and a -D option, name will be undefined regardless of the order of the options. Additional implementation-dependent names may be provided by the compiler. Implementat= ions support at least 2048 bytes of -D definitions and 256 names.=20 I did not find a justification for the current gcc behavior. Searching reve= aled a patch which implemented the behavior: http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00621.html and two messages earlier that year which might be relevant: http://gcc.gnu.org/ml/gcc/2000-09/msg00673.html http://gcc.gnu.org/ml/gcc-patches/2000-08/msg01271.html The original bug report was: http://gcc.gnu.org/ml/gcc-bugs/2000-08/msg00605.html Neither message mentions a possible dependency to the unix specification. Three years later the code went from the preprocessor to the frontend http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01432.html I now have two questions: 1) Does anybody recall a discussion of this topic? 2) Is this a bug? Erwin