Serious error-causing change in new CPP's -traditional behavior

[Jason R Thorpe]

There is a change in new CPP's behavior when -traditional is used, which
causes the NetBSD/i386 kernel build to fail.  Not only is the behavior
different than the CPP in EGCS 1.1.2, but it appears to be inconsistent
with itself .. i.e. similar input is apparently processed differently
when it should not be.

The code that it actually chokes on is a large, complicated macro that
generates interrupt stubs, but I have a simple test case that demonstrates
the problem.

The input is the followng:

 ----- begin sample ------

#define	XINTR(irq_num)		Xintr/**/irq_num

#define	IDTVEC(name)	.globl X/**/name; X/**/name:

#define	INTR(irq_num) \
IDTVEC(resume/**/irq_num) ;\
	cli ;\
	jmp 1f ;\
XINTR(irq_num): ;\
	pushl $0

INTR(666)

 ----- end sample -----

GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (80386, BSD syntax)

.globl Xresume666; Xresume666: ;        cli ;Xintr666: ;        pushl $0


GNU CPP version 2.96 20000504 (experimental) (cpplib)
 (NetBSD/i386 ELF)

 .globl Xresume666; Xresume666: ; cli ;Xintr 666: ; pushl $0


Note that with 20000504's CPP, the `Xintr666' is miswritten as `Xintr 666'.

For the record, the full command that caused the error is:

dr-evil:thorpej 4$ /usr/local/bin/gcc -v -x assembler-with-cpp -traditional-cp>
Reading specs from /usr/local/lib/gcc-lib/i386-unknown-netbsdelf1.4X/2.96/specs
gcc version 2.96 20000504 (experimental)
 /usr/local/lib/gcc-lib/i386-unknown-netbsdelf1.4X/2.96/cpp -lang-asm -nostdinc -v -I. -I../../../../arch -I../../../.. -I../../../../../gnu/sys -$ -D__NetBSD__ -D__ELF__ -D__NO_LEADING_UNDERSCORES__ -Di386 -D__NetBSD__ -D__ELF__ -D__NO_LEADING_UNDERSCORES__ -D__i386__ -D__i386 -Asystem(unix) -Asystem(NetBSD) -Acpu(i386) -Amachine(i386) -D__ASSEMBLER__ -traditional -D_LOCORE -DLKM -DDIAGNOSTIC -DMAXUSERS=32 -D_KERNEL -Di386 ../../../../arch/i386/i386/locore.s /var/tmp/cc7jT3C4.s
GNU CPP version 2.96 20000504 (experimental) (cpplib)
 (NetBSD/i386 ELF)
#include "..." search starts here:
#include <...> search starts here:
 .
 ../../../../arch
 ../../../..
 ../../../../../gnu/sys
End of search list.
 as -o locore.o /var/tmp/cc7jT3C4.s
/var/tmp/cc7jT3C4.s: Assembler messages:
/var/tmp/cc7jT3C4.s:6303: Error: no such 386 instruction: `xintr'
/var/tmp/cc7jT3C4.s:6303: Error: Ignoring junk '0' after expression
/var/tmp/cc7jT3C4.s:6303: Error: Ignoring junk '0' after expression
/var/tmp/cc7jT3C4.s:6304: Error: no such 386 instruction: `xintr'
/var/tmp/cc7jT3C4.s:6304: Error: Ignoring junk '1' after expression
/var/tmp/cc7jT3C4.s:6304: Error: Ignoring junk '1' after expression
/var/tmp/cc7jT3C4.s:6305: Error: no such 386 instruction: `xintr'
/var/tmp/cc7jT3C4.s:6305: Error: Ignoring junk '2' after expression
/var/tmp/cc7jT3C4.s:6305: Error: Ignoring junk '2' after expression
.
.
.


Now, note that 20000504's CPP correctly concatenated `Xresume666'.  Perhaps
it has to do with the fact that comment characters are appearing within
a macro argument, and thus take a different code path to comment elimination.

I took a quick glance, but this is really the first time I've looked inside
the new cpplib at all, and so I would appreciate an opinion from someone
who's familiar with the guts of cpplib.

I don't know if this is or isn't related to the current thread regarding
the new CPP and imake ... I must admit that I haven't had the time to
pay much attention to that thread.

However, I think this is a serious problem ... I'd wager that there's
a fair bit of code out there that is derived from older code that uses
the traditional Reiser CPP comment elimination semantics for concatenation.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>