The following stabs output is generated after pch_init is called in
the decl-3.h test:

	.stabs	"foo_p:t16=17=*18=xsfoo:",128,0,2,0

Breakpoint 1, pch_init () at ../../gcc/gcc/c-family/c-pch.c:161
161	  (*debug_hooks->handle_pch) (0);
(gdb) c
Continuing.

Breakpoint 4, dbxout_begin_complex_stabs () at ../../gcc/gcc/dbxout.c:620
620	  emit_pending_bincls_if_required ();
(gdb) bt
#0  dbxout_begin_complex_stabs () at ../../gcc/gcc/dbxout.c:620
#1  0x0088317c in dbxout_symbol (decl=0x7ae37ee0, local=0)
    at ../../gcc/gcc/dbxout.c:2816
#2  0x00876834 in dbxout_type_decl (decl=0x7ae37ee0, local=0)
    at ../../gcc/gcc/dbxout.c:1388
#3  0x010fc0ec in rest_of_decl_compilation (decl=0x7ae37ee0, top_level=1, 
    at_end=0) at ../../gcc/gcc/passes.c:196
#4  0x000bb148 in finish_decl (decl=0x7ae37ee0, init_loc=0, init=0x0, 
    origtype=0x0, asmspec_tree=0x0) at ../../gcc/gcc/c/c-decl.c:4490
#5  0x001bb6f0 in c_parser_declaration_or_fndef (parser=0x7aeb2aa0, 
    fndef_ok=0 '\000', static_assert_ok=1 '\001', empty_ok=1 '\001', 
    nested=0 '\000', start_attr_ok=1 '\001', 
    objc_foreach_object_declaration=0x0) at ../../gcc/gcc/c/c-parser.c:1665
#6  0x001bad54 in c_parser_external_declaration (parser=0x7aeb2aa0)
    at ../../gcc/gcc/c/c-parser.c:1362
#7  0x001ba744 in c_parser_translation_unit (parser=0x7aeb2aa0)
    at ../../gcc/gcc/c/c-parser.c:1250
#8  0x001d8a98 in c_parse_file () at ../../gcc/gcc/c/c-parser.c:10836
#9  0x003211c0 in c_common_parse_file ()
    at ../../gcc/gcc/c-family/c-opts.c:1137
#10 0x012ccf80 in compile_file () at ../../gcc/gcc/toplev.c:546
#11 0x012d0420 in do_compile () at ../../gcc/gcc/toplev.c:1863
#12 0x012d070c in toplev_main (argc=16, argv=0x7eff0544)
---Type <return> to continue, or q <return> to quit---
    at ../../gcc/gcc/toplev.c:1939
#13 0x0424e104 in main (argc=16, argv=0x7eff0544) at ../../gcc/gcc/main.c:36

I just noticed that the tests no longer ICE:

FAIL: gcc.dg/pch/decl-3.c  -O0 -g assembly comparison
FAIL: gcc.dg/pch/decl-3.c   -O3 -g  assembly comparison
FAIL: gcc.dg/pch/decl-4.c  -O0 -g assembly comparison
FAIL: gcc.dg/pch/decl-4.c   -O3 -g  assembly comparison
FAIL: gcc.dg/pch/struct-1.c  -O0 -g assembly comparison
FAIL: gcc.dg/pch/struct-1.c   -O3 -g  assembly comparison
FAIL: gcc.dg/pch/system-1.c  -O0 -g assembly comparison
FAIL: gcc.dg/pch/system-1.c   -O3 -g  assembly comparison

FAIL: g++.dg/pch/array-1.C  -g assembly comparison
FAIL: g++.dg/pch/array-1.C  -O2 -g assembly comparison
FAIL: g++.dg/pch/externc-1.C  -g assembly comparison
FAIL: g++.dg/pch/externc-1.C  -O2 -g assembly comparison
FAIL: g++.dg/pch/static-1.C  -g assembly comparison
FAIL: g++.dg/pch/static-1.C  -O2 -g assembly comparison
FAIL: g++.dg/pch/system-1.C  -g assembly comparison
FAIL: g++.dg/pch/system-1.C  -O2 -g assembly comparison
FAIL: g++.dg/pch/system-2.C  -g assembly comparison
FAIL: g++.dg/pch/system-2.C  -O2 -g assembly comparison
FAIL: g++.dg/pch/uninst.C  -g assembly comparison
FAIL: g++.dg/pch/uninst.C  -O2 -g assembly comparison
FAIL: g++.dg/pch/wchar-1.C  -g assembly comparison
FAIL: g++.dg/pch/wchar-1.C  -O2 -g assembly comparison

The assembly comparison errors seem to be caused by the same
problem as before:

PASS: gcc.dg/pch/decl-3.c  -O0 -g -I. -Dwithout_PCH (test for excess errors)
line #31<       .stabs  "foo_p:t16=17=*18=xsfoo:",128,0,2,0>       .SPACE $TEXT$
line #32<       .SPACE $TEXT$>       .NSUBSPA $CODE$
line #33
<       .NSUBSPA $CODE$
>       .align 4

Broken by Steven's PCH changes.
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188856
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189482

(from r188856 to r189481 this ICEd, afterwards it just results in assembly comparison differences.
Can be reproduced even on x86_64-linux, e.g. with
make check-gcc RUNTESTFLAGS='--target_board=unix/-m32/-gstabs pch.exp=decl-3*'

The saving/restoring of assembly directives has been there clearly for a reason, so needs to be replaced or the changes reverted.

Not sure if stabs + PCH warrants a P1 regression though.

The problem is that dbxout.c (unlike dwarf2out.c; not sure about other debug backends) emits assembly immediately into asm_out_file, pretty much everywhere, instead of creating data structures from it and emitting everything only during the finish debughook.  So, if you'd like to avoid reversion of the patch, I'm afraid you'd pretty much need to implement the same thing, at least for dbxout (that, in between pch_init (but not earlier, you don't want to duplicate the stabs created before that) and pch_write the stabs will be say queued into some GC memory block and that GC memory block will be printed into assembly upon reading of pch or so.  I doubt fmemopen or similar is portable enough, so you'd need to rewrite all the dbxout.c code that right now uses fwrite/fputc/putc etc. to use some other interfaces and conditionally either append to the GC string, or write into asm_out_file.  Or rewrite dbxout.c to queue up everything, not sure if it wouldn't break anything if emitted at the end of assembly though.

Thanks for analyzing this.

I think reverting would be backward - we should clearly move forward.  One
way forward is to simply declare PCH unsupported with stabs.

The issue can be reproduced on x86_64 with -gstabs btw:

make check-gcc RUNTESTFLAGS="--target_board=unix/-gstabs pch.exp"
Running /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pch/pch.exp ...
FAIL: gcc.dg/pch/decl-3.c  -O0 -g assembly comparison
FAIL: gcc.dg/pch/decl-3.c   -O0  assembly comparison
FAIL: gcc.dg/pch/decl-3.c   -O1  assembly comparison
FAIL: gcc.dg/pch/decl-3.c   -O2  assembly comparison
FAIL: gcc.dg/pch/decl-3.c   -O3 -fomit-frame-pointer  assembly comparison
FAIL: gcc.dg/pch/decl-3.c   -O3 -g  assembly comparison
FAIL: gcc.dg/pch/decl-3.c   -Os  assembly comparison
FAIL: gcc.dg/pch/decl-4.c  -O0 -g assembly comparison
FAIL: gcc.dg/pch/decl-4.c   -O0  assembly comparison
...

Another hack would be to s/asm_out_file/dbx_out_file/ in dbxout.c and
switch it to a temporary file during PCH generation, in the handle_pch
hook then read its contents and store it into the PCH.

dbxout.c already defines a handle_pch hook, so it is apparently told when pch_init and write_pch are called, so in theory this could be handled in dbxout.c only (still, the question is if other debug backends don't have similar issue).

Note this isn't limited to dbxout.c, pretty much all *out.c debug backends but dwarf2out.c suffer from these issues, they all emit assembly immediately, only dwarf2out.c just creates data structures to be used later on.

> I think reverting would be backward - we should clearly move forward.  One
> way forward is to simply declare PCH unsupported with stabs.

This is what I think we should do about this bug. The problem isn't
limited to PCH, it also happens with other "delayed" outputs. For
instance, there's stabs info for symbols not emitted at all by
cgraphunit, and debug info isn't emitted at all with LTO.

The DWARF-to-*out debug translator should be the way forward IMHO.
It'd simplify many things in GCC internals. I might give it a stab (no
pun...) for GCC 4.9, but for GCC 4.8 I really don't see any way to fix
this issue.

All that to avoid one #include "output.h" in one file?  That doesn't seem appropriate to me.  I'm not questioning it is a desirable change, but I'd reapply it only when all the *out.c backends are converted to emit delayed info, or when (if ever) a dwarf2 -> something else converters are written.

> All that to avoid one #include "output.h" in one file?

Is that one little thing really the only change you see? I see a
different picture.

The change is a major step in the direction of making a clear cut
between the middle/back end and the front ends. A front end should not
output assembly, period, if we want the front ends to become separate
libraries, in the long run, that can be used by external tools (static
checkers, IDEs, etc.) like clang. For the long term, this is IMHO the
only viable solution for keeping the GCC front ends relevant.

The change also allows the compiler to open the assembler file in
write-only mode and to open it only after the front end is done. My
plan is to postponed it even further: for GCC 4.9 I'd like to work on
streaming slim LTO objects directly to a .o file, without going
through an assembler file at all (this is relatively simple for ELF
targets).

Finally, the change also simplifies the PCH mechanism further. If
we're ever going to replace PCH-as-a-memory-dump with something
streamed, we'll have to make an effort at only streaming IR objects,
not assembler output.

Had I known this change would break stabs like this, I'd obviously
have tried to solve that problem first. But to back out the change now
would be a mistake. Nobody is going to fix those *out.c back ends, as
you very well know.

(In reply to comment #11)
> > All that to avoid one #include "output.h" in one file?
> 
> Is that one little thing really the only change you see? I see a
> different picture.
> 
> The change is a major step in the direction of making a clear cut
> between the middle/back end and the front ends. A front end should not
> output assembly, period, if we want the front ends to become separate
> libraries, in the long run, that can be used by external tools (static
> checkers, IDEs, etc.) like clang. For the long term, this is IMHO the
> only viable solution for keeping the GCC front ends relevant.
> 
> The change also allows the compiler to open the assembler file in
> write-only mode and to open it only after the front end is done. My
> plan is to postponed it even further: for GCC 4.9 I'd like to work on
> streaming slim LTO objects directly to a .o file, without going
> through an assembler file at all (this is relatively simple for ELF
> targets).
> 
> Finally, the change also simplifies the PCH mechanism further. If
> we're ever going to replace PCH-as-a-memory-dump with something
> streamed, we'll have to make an effort at only streaming IR objects,
> not assembler output.
> 
> Had I known this change would break stabs like this, I'd obviously
> have tried to solve that problem first. But to back out the change now
> would be a mistake. Nobody is going to fix those *out.c back ends, as
> you very well know.

That's exactly my thinking of the whole picture.

Timing seems to be bad now - so as compromise I'd accept reverting the
patch for 4.8 and immediately re-installing it when stage1 for 4.9
re-opens.

If dwarf2out.c is really set up nicely enough (just dump
its internal dwarf tree to asm_out_file at some point) then doing
dwarf -> Y translation at that point should be possible.  Of course
I don't see anybody doing that either - nobody is really interested
in debug formats besides dwarf apart from keeping the legacy going.
IMHO we can direct them to use oder versions of GCC.

Thus, let's deprecate anything but dwarf in 4.8 ;)

Why is this P1 for GCC 4.8? This is only a problem for some non-DWARF
targets, but all primary targets have DWARF.

I believe it would be possible to implement dwarf on 32-bit hppa-hpux...

--
John David Anglin	dave.anglin@bell.net

Because -gstabs etc. are still supported on most of the primary and secondary targets, and (to my surprise) some projects are still using it (I believe e.g. some Mozilla builds do as their bugreporting system only supports STABS, not DWARF).  STABS hasn't been deprecated, so we can't just remove that support for 4.8 easily, yeah, we should probably deprecate it and remove later on.

I find myself in agreement with Richi in c#12.   I'm going to revert the problematical patch for the 4.8 tree.  I'll attach the patch to the 4.9 pending patches meta bug so it can be reinstalled after 4.8 branches and 4.9 opens.

(In reply to comment #16)
> I find myself in agreement with Richi in c#12.

Does that also apply to the "Thus, let's deprecate anything but dwarf
in 4.8" part? Otherwise, we still need to look at other solutions for
GCC 4.9.  I have done some work on making stabs output work with fake
top-level asms before CGRAPH_STATE_FINISHED, but IMHO dropping stabs
support, or at least stabs+PCH support, for GCC 4.9 would be a better
long-term "solution".

Yes, I am in favor of deprecating everything but dwarf for 4.9; however, that's a significant enough change that we probably need to discuss it on the lists.

I think in the release after next we can just deprecate stabs and all other non-dwarf debug formats (not remove them) and simply not worry about it.  In the release after that, we then remove them.  If someone doesn't like that, let them step forward as a stabs maintainer and fix it before release.  This gives them 2 years to fix it or so.  If they don't, then removal seems reasonable.

Author: jakub
Date: Mon Feb 18 19:42:56 2013
New Revision: 196124

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196124
Log:
	PR pch/54117
	* c-opts.c (c_common_post_options): If debug info is enabled
	and non-dwarf*, refuse to load PCH files and when writing PCH
	file warn.

	* lib/dg-pch.exp (pch-init, pch-finish,
	check_effective_target_pch_supported_debug): New procs.
	(dg-flags-pch): If $pch_unsupported, make tests UNSUPPORTED.
	Likewise if $pch_unsupported_debug and $flags include -g.
	Skip FAILs about missing *.gch file if $pch_unsupported_debug
	and dg-require-effective-target pch_unsupported_debug.
	* g++.dg/pch/pch.exp: Call pch-init and pch-finish.
	* objc.dg/pch/pch.exp: Likewise.
	* gcc.dg/pch/pch.exp: Likewise.
	* gcc.dg/pch/valid-1.c: Add dg-require-effective-target
	pch_unsupported_debug.
	* gcc.dg/pch/valid-1.hs: Likewise.
	* gcc.dg/pch/valid-1b.c: Likewise.
	* gcc.dg/pch/valid-1b.hs: Likewise.

Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-opts.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/pch/pch.exp
    trunk/gcc/testsuite/gcc.dg/pch/pch.exp
    trunk/gcc/testsuite/gcc.dg/pch/valid-1.c
    trunk/gcc/testsuite/gcc.dg/pch/valid-1.hs
    trunk/gcc/testsuite/gcc.dg/pch/valid-1b.c
    trunk/gcc/testsuite/gcc.dg/pch/valid-1b.hs
    trunk/gcc/testsuite/lib/dg-pch.exp
    trunk/gcc/testsuite/objc.dg/pch/pch.exp

Fixed by disabling PCH if producing debug info other than DWARF*.