[Bug pch/30702] New: PCH vs not closing a function in a header

[Bug pch/30702] New: PCH vs not closing a function in a header

[pinskia at gcc dot gnu dot org]

t.h:
int f(void)
{

--------- cut -----
t.c
#include <t.h>

return 0;
}

--------- cut -----
gcc t.c
works
but
gcc t.h && gcc t.c

fails to compile t.h.
As far as I can tell this is not a regression


-- 
           Summary: PCH vs not closing a function in a header
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: pch
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30702

[Bug pch/30702] PCH vs not closing a function in a header

[tromey at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]



------- Comment #1 from tromey at gcc dot gnu dot org  2007-04-25 01:20 -------
Hmm.  "gcc t.h" fails and prints an error:

opsy. gcc t.h
t.h: In function ‘f’:
t.h:2: error: expected declaration or statement at end of input

However it also leaves a t.h.gch file, which seems a bit weird.

Anyway I don't understand why this is a bug.  Surely this is a pathological
case that is reasonable for PCH to reject.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30702

[Bug pch/30702] PCH vs not closing a function in a header

[pinskia at gcc dot gnu dot org]

------- 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:
apinski@debian:~$ ~/x86-local-fsf/bin/gcc t.h
t.h: In function 'f':
t.h:2: error: expected declaration or statement at end of input
apinski@debian:~$ ~/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
apinski@debian:~$ !rm
rm t.h.*
apinski@debian:~$ ~/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

[Bug pch/30702] PCH vs not closing a function in a header

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-20 11:22 -------
More proper bugreport is PR33980.

*** This bug has been marked as a duplicate of 33980 ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30702