Re: GCC Pre-processor bug?

[Geoff Keating <geoffk at geoffk dot org>]

nismo@freeuk.com writes:

> Hello.
> 
> I am using gcc on RedHat linux and I seem to be experiencing a bug in the
> gcc prerocessor. I am trying to use the "Concat..." macros from the "Imake"
> build but I am finding that there is a fundamental instance where they fail.
> I have traced this to a number of "nuances" in gcc itself.
> 
> First, the machine and gcc details:
> 
> $ uname -a
> Linux <hostname> 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
> gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
> $
> 
> Now the problem. Please forgive me for supplying this in a possible two-
> file scenario but in this form I don't have to butcher "Imake" itself...
> 
> Consider the following Imake.tmpl and Imakefile:
> 
> /************************************************** Start of Imake.tmpl */
> #define Concat3(a,b,c)a/**/b/**/c
> 
> #include INCLUDE_IMAKEFILE
> /**************************************************** End of Imake.tmpl */
> 
> /*************************************************** Start of Imakefile */
> #define PathChar /
> 
> DIRNAME=Concat3(Parent,PathChar,Child)
> /***************************************************** End of Imakefile */
> 
> The problem is that when gcc is run with the "-traditional" flag, the output
> within the resultant "Makefile" looks as follows:
> 
> ParentPathCharChild
> 
> which is wrong. What I'm trying to get is:
> 
> Parent/Child
> 
> and the reason I'm not getting it is because macro expansion for parameters
> of the Concat() macro is being attempted *after* the expansion of the macro
> itself. Shouldn't it be done before? Is this intentional?

To show a bug in gcc's -traditional mode, you have to show that
it behaves differently to traditional C preprocessors. 

When I try this on the bundled compiler on SunOS 4.1.3, it produces

DIRNAME=ParentPathCharChild

and so GCC is behaving correctly in this case. 

> The definition of Imake.tmpl can be changed to the following in an attempt
> to fix the problem. This fix works on some other compilers, but not on gcc:
> 
> /************************************************** Start of Imake.tmpl */
> #define _Concat3(a,b,c)a##b##c
> #define Concat3(a,b,c)_Concat3(a,b,c)
> 
> #include INCLUDE_IMAKEFILE
> /***************************************************** End of Imakefile */

This won't work.  Traditional C preprocessors do not support ## string
concatenation.

> However, if I butcher "Imake" and remove the "-traditional" option from the
> gcc command line, we now get:
> 
>   Parent/Child
> 
> which is correct *except* for the spurious whitespace on the front. Each
> macro expansion that is done generates a spurious leading whitespace! This
> makes usage of this macro impossible if the expanded output of the macro
> needs to start from column one.

GCC does not support the use of the non-traditional C preprocessor for
anything other that C, C++, assembler, and possibly Fortran.  It
especially does not support it for Makefiles.  This behaviour will be
the least of your problems.

> I would appreciate any comments and details of any known workarounds, if
> there are any.

You probably want to wrap the 'Concat3' macro in another macro, like

#define Concat3_2(a,b,c) Concat3(a,b,c)
DIRNAME=Concat3_2(Parent,PathChar,Child)

-- 
- Geoffrey Keating <geoffk@cygnus.com>