* Re: more pch questions @ 2003-03-11 19:05 Benjamin Kosnik 2003-03-11 19:29 ` Geoffrey Keating 0 siblings, 1 reply; 8+ messages in thread From: Benjamin Kosnik @ 2003-03-11 19:05 UTC (permalink / raw) To: geoffk; +Cc: gcc Hmmm. You keep saying this, and I keep telling you that -Winvalid-pch doesn't hack it. So. In this case, when I'm compiling with a found .gch file, and it's found to be invalid, -Winvalid-pch says nothing. Can you please take a look at this? -benjamin ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: more pch questions 2003-03-11 19:05 more pch questions Benjamin Kosnik @ 2003-03-11 19:29 ` Geoffrey Keating 2003-03-12 7:22 ` Benjamin Kosnik 0 siblings, 1 reply; 8+ messages in thread From: Geoffrey Keating @ 2003-03-11 19:29 UTC (permalink / raw) To: Benjamin Kosnik; +Cc: gcc On Tuesday, March 11, 2003, at 11:01 AM, Benjamin Kosnik wrote: > > Hmmm. You keep saying this, and I keep telling you that -Winvalid-pch > doesn't hack it. > > So. In this case, when I'm compiling with a found .gch file, and it's > found to be invalid, -Winvalid-pch says nothing. You're saying that execution reaches the fail: label in cpp_valid_state. Execution can't fall through to there, there are only three places that have 'goto fail' in that routine, and each one has a call to cpp_error right before it, switched on by 'warn_invalid_pch'. So, if -Winvalid-pch says nothing, then there's something very wrong, maybe a codegen problem in the stage1 compiler. I don't have very much time to be debugging these problems; I have other, more serious problems that I must fix first (at the moment, I'm working on #import, which is a complete showstopper for Apple). It would help a lot if you could produce simple testcases that I don't need to apply compiler patches to run. -- Geoff Keating <geoffk@apple.com> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: more pch questions 2003-03-11 19:29 ` Geoffrey Keating @ 2003-03-12 7:22 ` Benjamin Kosnik 2003-03-12 7:46 ` Gareth Pearce 2003-03-12 20:08 ` Geoff Keating 0 siblings, 2 replies; 8+ messages in thread From: Benjamin Kosnik @ 2003-03-12 7:22 UTC (permalink / raw) To: Geoffrey Keating; +Cc: gcc >You're saying that execution reaches the fail: label in >cpp_valid_state. Execution can't fall through to there, there are only >three places that have 'goto fail' in that routine, and each one has a >call to cpp_error right before it, switched on by 'warn_invalid_pch'. Yes. >So, if -Winvalid-pch says nothing, then there's something very wrong, >maybe a codegen problem in the stage1 compiler. No. -Winvalid-pch says nothing because in _cpp_begin_message, switch (level) { case DL_WARNING: case DL_PEDWARN: if (CPP_IN_SYSTEM_HEADER (pfile) && ! CPP_OPTION (pfile, warn_system_headers)) return 0; returns zero, because the pch in question includes files marked as system headers (C++ <string>) and I didn't specify -Winvalid-pch -Wsystem-headers When I do, I get: In file included from test_pch.cc:1: /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/string:45:20: warning: /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/stdc++.h.gch: not used because `_CPP_STRING' is defined Perhaps a better way of getting this message would be to use DL_WARNING_SYSHDR, not DL_WARNING in cpp_valid_state. See attached patch. There are other, perhaps unrelated problems with pch files and system headers (see other/9471). I'm still not quite sure what the error message, when I can see it, means. Any insights? Why does _CPP_STRING being defined matter? Since the generated pch file is invalid, I'll try to fix this as well. -benjamin 2003-03-11 Benjamin Kosnik <bkoz@redhat.com> * cpppch.c (cpp_valid_state): Use DL_WARNING_SYSHDR, not DL_WARNING so that errors in system includes are shown. Index: cpppch.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cpppch.c,v retrieving revision 1.2 diff -c -p -r1.2 cpppch.c *** cpppch.c 10 Jan 2003 02:21:59 -0000 1.2 --- cpppch.c 12 Mar 2003 04:50:47 -0000 *************** cpp_valid_state (r, name, fd) *** 417,423 **** || h->flags & NODE_POISONED) { if (CPP_OPTION (r, warn_invalid_pch)) ! cpp_error (r, DL_WARNING, "%s: not used because `%.*s' not defined", name, m.name_length, namebuf); goto fail; --- 417,423 ---- || h->flags & NODE_POISONED) { if (CPP_OPTION (r, warn_invalid_pch)) ! cpp_error (r, DL_WARNING_SYSHDR, "%s: not used because `%.*s' not defined", name, m.name_length, namebuf); goto fail; *************** cpp_valid_state (r, name, fd) *** 429,435 **** || memcmp (namebuf, newdefn, m.definition_length) != 0) { if (CPP_OPTION (r, warn_invalid_pch)) ! cpp_error (r, DL_WARNING, "%s: not used because `%.*s' defined as `%s' not `%.*s'", name, m.name_length, namebuf, newdefn + m.name_length, m.definition_length - m.name_length, --- 429,435 ---- || memcmp (namebuf, newdefn, m.definition_length) != 0) { if (CPP_OPTION (r, warn_invalid_pch)) ! cpp_error (r, DL_WARNING_SYSHDR, "%s: not used because `%.*s' defined as `%s' not `%.*s'", name, m.name_length, namebuf, newdefn + m.name_length, m.definition_length - m.name_length, *************** cpp_valid_state (r, name, fd) *** 454,460 **** || h->flags & NODE_POISONED) { if (CPP_OPTION (r, warn_invalid_pch)) ! cpp_error (r, DL_WARNING, "%s: not used because `%s' is defined", name, undeftab + i); goto fail; } --- 454,461 ---- || h->flags & NODE_POISONED) { if (CPP_OPTION (r, warn_invalid_pch)) ! cpp_error (r, DL_WARNING_SYSHDR, ! "%s: not used because `%s' is defined", name, undeftab + i); goto fail; } ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: more pch questions 2003-03-12 7:22 ` Benjamin Kosnik @ 2003-03-12 7:46 ` Gareth Pearce 2003-03-12 20:08 ` Geoff Keating 1 sibling, 0 replies; 8+ messages in thread From: Gareth Pearce @ 2003-03-12 7:46 UTC (permalink / raw) To: Benjamin Kosnik; +Cc: gcc > I'm still not quite sure what the error message, when I can see it, > means. Any insights? Why does _CPP_STRING being defined matter? pch tries to provide no visible difference between it being on and off. Therefore the status of #defines going into the header when its precompiled - and going into its use, must be identical - since otherwise theres potential for the pch to act differently to what would happen normally. Extremely smart pch - can probably get round some of these issues, but (last time I thought I had a clue about this stuff) it doesnt seem that in this case 'extremely smart' describes the pch stuff. here comes even more supposition: (NB - i'm just guessing, even if i dont quite sound like it) i assume your pch was created just by using g++ stdc++.h - where stdc++.h #includes all the standard headers. therefore other then <internal> - theres no #defines in its creation environment. Therefore you can't use it after you've defined anything. thats why the -include method works best, because it generally matches the creation environment, without thinking. Gareth ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: more pch questions 2003-03-12 7:22 ` Benjamin Kosnik 2003-03-12 7:46 ` Gareth Pearce @ 2003-03-12 20:08 ` Geoff Keating 2003-03-12 20:09 ` Daniel Jacobowitz 1 sibling, 1 reply; 8+ messages in thread From: Geoff Keating @ 2003-03-12 20:08 UTC (permalink / raw) To: Benjamin Kosnik; +Cc: gcc, gcc-patches Benjamin Kosnik <bkoz@redhat.com> writes: > -Winvalid-pch says nothing because in _cpp_begin_message, > > switch (level) > { > case DL_WARNING: > case DL_PEDWARN: > if (CPP_IN_SYSTEM_HEADER (pfile) > && ! CPP_OPTION (pfile, warn_system_headers)) > return 0; > > returns zero, because the pch in question includes files marked as > system headers (C++ <string>) and I didn't specify > > -Winvalid-pch -Wsystem-headers > > When I do, I get: > > In file included from test_pch.cc:1: > /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/string:45:20: > warning: > /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/stdc++.h.gch: not > used because `_CPP_STRING' is defined > > Perhaps a better way of getting this message would be to use DL_WARNING_SYSHDR, > not DL_WARNING in cpp_valid_state. See attached patch. There are other, > perhaps unrelated problems with pch files and system headers (see > other/9471). > > I'm still not quite sure what the error message, when I can see it, > means. Any insights? Why does _CPP_STRING being defined matter? It means that somewhere in the header you've precompiled, _CPP_STRING is used; and that you're defining _CPP_STRING on the command line (or before the PCH is included) when you're using the PCH but not when generating it. This changes the meaning of the PCH in a way that can't be easily handled, so to ensure correct compilation, the PCH isn't used. > Since the generated pch file is invalid, I'll try to fix this as well. This patch is OK, please commit it. > -benjamin > > 2003-03-11 Benjamin Kosnik <bkoz@redhat.com> > > * cpppch.c (cpp_valid_state): Use DL_WARNING_SYSHDR, not > DL_WARNING so that errors in system includes are shown. > > Index: cpppch.c > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/cpppch.c,v > retrieving revision 1.2 > diff -c -p -r1.2 cpppch.c > *** cpppch.c 10 Jan 2003 02:21:59 -0000 1.2 > --- cpppch.c 12 Mar 2003 04:50:47 -0000 > *************** cpp_valid_state (r, name, fd) > *** 417,423 **** > || h->flags & NODE_POISONED) > { > if (CPP_OPTION (r, warn_invalid_pch)) > ! cpp_error (r, DL_WARNING, > "%s: not used because `%.*s' not defined", > name, m.name_length, namebuf); > goto fail; > --- 417,423 ---- > || h->flags & NODE_POISONED) > { > if (CPP_OPTION (r, warn_invalid_pch)) > ! cpp_error (r, DL_WARNING_SYSHDR, > "%s: not used because `%.*s' not defined", > name, m.name_length, namebuf); > goto fail; > *************** cpp_valid_state (r, name, fd) > *** 429,435 **** > || memcmp (namebuf, newdefn, m.definition_length) != 0) > { > if (CPP_OPTION (r, warn_invalid_pch)) > ! cpp_error (r, DL_WARNING, > "%s: not used because `%.*s' defined as `%s' not `%.*s'", > name, m.name_length, namebuf, newdefn + m.name_length, > m.definition_length - m.name_length, > --- 429,435 ---- > || memcmp (namebuf, newdefn, m.definition_length) != 0) > { > if (CPP_OPTION (r, warn_invalid_pch)) > ! cpp_error (r, DL_WARNING_SYSHDR, > "%s: not used because `%.*s' defined as `%s' not `%.*s'", > name, m.name_length, namebuf, newdefn + m.name_length, > m.definition_length - m.name_length, > *************** cpp_valid_state (r, name, fd) > *** 454,460 **** > || h->flags & NODE_POISONED) > { > if (CPP_OPTION (r, warn_invalid_pch)) > ! cpp_error (r, DL_WARNING, "%s: not used because `%s' is defined", > name, undeftab + i); > goto fail; > } > --- 454,461 ---- > || h->flags & NODE_POISONED) > { > if (CPP_OPTION (r, warn_invalid_pch)) > ! cpp_error (r, DL_WARNING_SYSHDR, > ! "%s: not used because `%s' is defined", > name, undeftab + i); > goto fail; > } > -- - Geoffrey Keating <geoffk@geoffk.org> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: more pch questions 2003-03-12 20:08 ` Geoff Keating @ 2003-03-12 20:09 ` Daniel Jacobowitz 0 siblings, 0 replies; 8+ messages in thread From: Daniel Jacobowitz @ 2003-03-12 20:09 UTC (permalink / raw) To: Geoff Keating; +Cc: Benjamin Kosnik, gcc On Wed, Mar 12, 2003 at 11:20:23AM -0800, Geoff Keating wrote: > Benjamin Kosnik <bkoz@redhat.com> writes: > > > -Winvalid-pch says nothing because in _cpp_begin_message, > > > > switch (level) > > { > > case DL_WARNING: > > case DL_PEDWARN: > > if (CPP_IN_SYSTEM_HEADER (pfile) > > && ! CPP_OPTION (pfile, warn_system_headers)) > > return 0; > > > > returns zero, because the pch in question includes files marked as > > system headers (C++ <string>) and I didn't specify > > > > -Winvalid-pch -Wsystem-headers > > > > When I do, I get: > > > > In file included from test_pch.cc:1: > > /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/string:45:20: > > warning: > > /mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/stdc++.h.gch: not > > used because `_CPP_STRING' is defined > > > > Perhaps a better way of getting this message would be to use DL_WARNING_SYSHDR, > > not DL_WARNING in cpp_valid_state. See attached patch. There are other, > > perhaps unrelated problems with pch files and system headers (see > > other/9471). > > > > I'm still not quite sure what the error message, when I can see it, > > means. Any insights? Why does _CPP_STRING being defined matter? > > It means that somewhere in the header you've precompiled, _CPP_STRING > is used; and that you're defining _CPP_STRING on the command line (or > before the PCH is included) when you're using the PCH but not when > generating it. This changes the meaning of the PCH in a way that can't be > easily handled, so to ensure correct compilation, the PCH isn't used. Which presents the answer to Ben's problem. Ben, I bet you're including the PCH inside of the macro guards for the file, and it wants to be outside. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 8+ messages in thread
* more pch questions @ 2003-03-11 6:46 Benjamin Kosnik 2003-03-11 19:04 ` Geoffrey Keating 0 siblings, 1 reply; 8+ messages in thread From: Benjamin Kosnik @ 2003-03-11 6:46 UTC (permalink / raw) To: gcc; +Cc: geoffk Geoff. I'm debugging cc1plus when compiling the following % cat > test.cc #include <string> #include <vector> This is with the stdc++.h.gch patch as pointed out before, and a generated stdc++.h.gch that seems to be valid, and in the correct place as far as the search path. It looks like the stdc++.h.gch file is indeed found (open_file_pch), but ruled invalid in cpp_valid_state. (gdb) f #0 cpp_valid_state (r=0x85b8000, name=0xbfffdedc "/mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/stdc++.h.gch", fd=7) at /mnt/hd/src/gcc/gcc/cpppch.c:474 at the "lose" part of the function cpp_valid_state, ie cpppch.c: 473 fail: if (namebuf != NULL) free (namebuf); if (undeftab != NULL) free (undeftab); return 1; (gdb) p namebuf $54 = (unsigned char *) 0x85c7d28 "__GNUG__ 3EXP__ 1024 148623157e+308e-4932L" Is this a simple case of __GNUC__ vs __GNUG__ ?? -benjamin ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: more pch questions 2003-03-11 6:46 Benjamin Kosnik @ 2003-03-11 19:04 ` Geoffrey Keating 0 siblings, 0 replies; 8+ messages in thread From: Geoffrey Keating @ 2003-03-11 19:04 UTC (permalink / raw) To: Benjamin Kosnik; +Cc: gcc On Monday, March 10, 2003, at 09:25 PM, Benjamin Kosnik wrote: > > Geoff. > > I'm debugging cc1plus when compiling the following > > % cat > test.cc > #include <string> > #include <vector> > > This is with the stdc++.h.gch patch as pointed out before, and a > generated stdc++.h.gch that seems to be valid, and in the correct place > as far as the search path. > > It looks like the stdc++.h.gch file is indeed found (open_file_pch), > but > ruled invalid in cpp_valid_state. > > (gdb) f > #0 cpp_valid_state (r=0x85b8000, name=0xbfffdedc > "/mnt/hd/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/stdc++.h.gch", > fd=7) at /mnt/hd/src/gcc/gcc/cpppch.c:474 > > at the "lose" part of the function cpp_valid_state, ie cpppch.c: 473 > > fail: > if (namebuf != NULL) > free (namebuf); > if (undeftab != NULL) > free (undeftab); > return 1; > > (gdb) p namebuf > $54 = (unsigned char *) 0x85c7d28 "__GNUG__ 3EXP__ 1024 > 148623157e+308e-4932L" > > Is this a simple case of __GNUC__ vs __GNUG__ ?? Try using '-Winvalid-pch'. This will give you a human-readable message rather than having to use GDB. -- Geoff Keating <geoffk@apple.com> ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-03-12 20:08 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-03-11 19:05 more pch questions Benjamin Kosnik 2003-03-11 19:29 ` Geoffrey Keating 2003-03-12 7:22 ` Benjamin Kosnik 2003-03-12 7:46 ` Gareth Pearce 2003-03-12 20:08 ` Geoff Keating 2003-03-12 20:09 ` Daniel Jacobowitz -- strict thread matches above, loose matches on Subject: below -- 2003-03-11 6:46 Benjamin Kosnik 2003-03-11 19:04 ` Geoffrey Keating
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).