preprocessor: % as args to #defines

[Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>]

Hi,

I am facing a problem with a behavioral change in gcc:

Given this code fragment:
-- snip --
#define CONCAT1(a, b) CONCAT2(a, b)
#define CONCAT2(a, b) a ## b
#define REG(x) CONCAT1 (__REGISTER_PREFIX__, x)
-- snip --

Using this fragment from inside of a *.S-file with gcc-3.2.3 works
without any complaint:
# m68k-rtems4.6-gcc -P -E -Wall -o bla.i bla.S
# m68k-rtems4.6-gcc -P -E -Wall -ansi -o bla.i bla.S

With gcc-3.3.2, this happens:
# m68k-rtems4.7-gcc -P -E -Wall -o bla.i bla.S
=> No complaint, bla.i is being produced

# m68k-rtems4.7-gcc -P -E -Wall -ansi -o bla.i bla.S
bla.S:3:8: pasting "%" and "reg" does not give a valid preprocessing
token
=> Error, bla.i is not being produced

If using this fragment from inside of *.c-files, this happens:
# m68k-rtems4.6-gcc -P -E -Wall -o bla.i bla.c
bla.c:3:8: warning: pasting "%" and "reg" does not give a valid
preprocessing token
=> Warning, nevertheless bla.i is being produced.

# m68k-rtems4.6-gcc -P -E -Wall -ansi -o bla.i bla.c
bla.c:3:8: warning: pasting "%" and "reg" does not give a valid
preprocessing token
=> Warning, bla.i is being produced.

With gcc-3.3.2:
# m68k-rtems4.7-gcc -P -E -Wall -o bla.i bla.c
bla.c:3:8: pasting "%" and "reg" does not give a valid preprocessing
token
=> Error, no bla.i

# m68k-rtems4.7-gcc -P -E -Wall -ansi -o bla.i bla.c
bla.c:3:8: pasting "%" and "reg" does not give a valid preprocessing
token
=> Error, no bla.i


Apparent cause for gcc to complain is __REGISTER_PREFIX__ == % for
m68k-rtems*. 

The __REGISTER_PREFIX__ preprocessor trick above is known to have been
functional for more than 10 years. Even gcc itself uses it (cf.
gcc/config/m68klb1sf68.asm).

Now, gcc >= 3.3's behavior renders these macros non-functional.

Questions:
* How to re-write these macros into ansi-compliant form (I've tried to,
but no success until now)
* Why does gcc-3.3.x issue errors instead of warnings like gcc-3.2.x
did?
* Why does gcc-3.3.x behave differently on *.c and *.S file types?

Ralf