------- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-25 01:27 -------
> However it also leaves a t.h.gch file, which seems a bit weird.
That in itself is a bug and maybe the real bug here :)
as if you do:
[EMAIL PROTECTED]:~$ ~/x86-local-fsf/bin/gcc t.h
t.h: In function 'f':
t.h:2: error: expected declaration or statement at end of input
[EMAIL PROTECTED]:~$ ~/x86-local-fsf/bin/gcc t.c
t.c:3: error: expected identifier or '(' before 'return'
t.c:4: error: expected identifier or '(' before '}' token
[EMAIL PROTECTED]:~$ !rm
rm t.h.*
[EMAIL PROTECTED]:~$ ~/x86-local-fsf/bin/gcc t.c
/usr/lib/crt1.o(.text+0x18): In function `_start':
../sysdeps/i386/elf/start.S:98: undefined reference to `main'
collect2: ld returned 1 exit status
So we reject the PCH building but don't delete the PCH file and then we try to
compile the valid source the failure happens but if we delete the PCH, it works
(note I changed <t.h> to "t.h").
> Anyway I don't understand why this is a bug. Surely this is a pathological
> case that is reasonable for PCH to reject.
Because PCH should be allow valid code to work even if it is a pathologicial
case. Yes I make sometimes weird testcases but maybe what I am trying to point
out is that PCH is broken.
This happens with both the C and C++ front-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30702
