* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
@ 2020-11-25 16:27 ` jakub at gcc dot gnu.org
2020-11-25 17:02 ` pinskia at gcc dot gnu.org
` (23 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-25 16:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The two options together make no sense. -g3 asks for all macros to be recorded
in the debug info and thus they need to be emitted, -P asks not to do that.
So, it is all about which of the two options takes precedence.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
2020-11-25 16:27 ` [Bug debug/97989] " jakub at gcc dot gnu.org
@ 2020-11-25 17:02 ` pinskia at gcc dot gnu.org
2020-11-25 17:07 ` jakub at gcc dot gnu.org
` (22 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-11-25 17:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
-g3 enables -dD
Kinda of documented by:
Level 3 includes extra information, such as all the macro definitions present
in the program. Some debuggers support macro expansion when you use -g3.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
2020-11-25 16:27 ` [Bug debug/97989] " jakub at gcc dot gnu.org
2020-11-25 17:02 ` pinskia at gcc dot gnu.org
@ 2020-11-25 17:07 ` jakub at gcc dot gnu.org
2020-11-25 17:10 ` stsp at users dot sourceforge.net
` (21 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-25 17:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Plus the -P option is documented to inhibit only line markers, not are
proprocessing directives like what -dD, -dM, -dN, -dI, -dU or -g3 emit.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (2 preceding siblings ...)
2020-11-25 17:07 ` jakub at gcc dot gnu.org
@ 2020-11-25 17:10 ` stsp at users dot sourceforge.net
2020-11-25 17:13 ` jakub at gcc dot gnu.org
` (20 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-25 17:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #4 from Stas Sergeev <stsp at users dot sourceforge.net> ---
Jakub, people use "cc -E -Wp,-P $CFLAGS" as a generic
preprocessor. $CFLAGS is needed to specify the includes,
but all other options do never affect -E.
But if CFLAGS contains -g3, you suddenly can't do that!
> -g3 enables -dD
Not letting people to use "cc -E -Wp,-P $CFLAGS" as a
generic preprocessor, is a very bad idea.
If -g3 enables -dD, then perhaps -P should disable it?
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (3 preceding siblings ...)
2020-11-25 17:10 ` stsp at users dot sourceforge.net
@ 2020-11-25 17:13 ` jakub at gcc dot gnu.org
2020-11-25 17:21 ` stsp at users dot sourceforge.net
` (19 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-25 17:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Then they just make bad assumptions. You can do:
cc -E -Wp,-P $CFLAGS -g0
instead if you are sure CFLAGS don't include the -d[DMNIU] options nor e.g.
-fdirectives-only.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (4 preceding siblings ...)
2020-11-25 17:13 ` jakub at gcc dot gnu.org
@ 2020-11-25 17:21 ` stsp at users dot sourceforge.net
2020-11-25 17:39 ` jakub at gcc dot gnu.org
` (18 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-25 17:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #6 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Jakub Jelinek from comment #5)
> Then they just make bad assumptions. You can do:
> cc -E -Wp,-P $CFLAGS -g0
> instead if you are sure CFLAGS don't include the -d[DMNIU] options nor e.g.
> -fdirectives-only.
$ gcc -g3 -E -Wp,-P -xc -g0 - </dev/null
still produces all the output, and it seems to
match your criteria, i.e. CFLAGS don't include the -d[DMNIU].
Besides, I don't see the -d0 or whatever to undo
the previously enabled (by -g3) -dD, so I would
be very surprised if the trailing -g0 worked that
way (and it does not).
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (5 preceding siblings ...)
2020-11-25 17:21 ` stsp at users dot sourceforge.net
@ 2020-11-25 17:39 ` jakub at gcc dot gnu.org
2020-11-25 17:44 ` stsp at users dot sourceforge.net
` (17 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-25 17:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 49627
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49627&action=edit
gcc11-pr97989.patch
That can be handled by this patch. But we can't retroactively apply it to
released versions (and it is as a behavior change inappropriate for release
branches either). So you need to filter out -g3 out of the flags yourself
then,
like one needs to filter out the above mentioned -d* options anyway.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (6 preceding siblings ...)
2020-11-25 17:39 ` jakub at gcc dot gnu.org
@ 2020-11-25 17:44 ` stsp at users dot sourceforge.net
2020-11-25 17:46 ` jakub at gcc dot gnu.org
` (16 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-25 17:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #8 from Stas Sergeev <stsp at users dot sourceforge.net> ---
Thanks, but what will this patch do?
Will it allow the trailing -g0, or what?
For example if you implement -d0 or alike to undo
the effect of previously specified -dD, will this
still break the release branches? I suppose not?
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (7 preceding siblings ...)
2020-11-25 17:44 ` stsp at users dot sourceforge.net
@ 2020-11-25 17:46 ` jakub at gcc dot gnu.org
2020-11-25 17:50 ` stsp at users dot sourceforge.net
` (15 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-25 17:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It will allow -g0 at the end to override the earlier -g3 and not add -dD in
that case.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (8 preceding siblings ...)
2020-11-25 17:46 ` jakub at gcc dot gnu.org
@ 2020-11-25 17:50 ` stsp at users dot sourceforge.net
2020-11-25 17:51 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-25 17:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #10 from Stas Sergeev <stsp at users dot sourceforge.net> ---
Ah, cool, thanks.
Should this be re-opened?
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (9 preceding siblings ...)
2020-11-25 17:50 ` stsp at users dot sourceforge.net
@ 2020-11-25 17:51 ` jakub at gcc dot gnu.org
2020-11-25 18:05 ` stsp at users dot sourceforge.net
` (13 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-25 17:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2020-11-25
Resolution|INVALID |---
Ever confirmed|0 |1
Status|RESOLVED |REOPENED
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (10 preceding siblings ...)
2020-11-25 17:51 ` jakub at gcc dot gnu.org
@ 2020-11-25 18:05 ` stsp at users dot sourceforge.net
2020-11-25 18:14 ` jakub at gcc dot gnu.org
` (12 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-25 18:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #12 from Stas Sergeev <stsp at users dot sourceforge.net> ---
Will your patch also fix this:
$ cpp -g3 -P -xc -g0 - </dev/null
It also produces the same output!
Why cpp reacts on those -g at all?
Shouldn't it only react on -dD?
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (11 preceding siblings ...)
2020-11-25 18:05 ` stsp at users dot sourceforge.net
@ 2020-11-25 18:14 ` jakub at gcc dot gnu.org
2020-11-25 18:22 ` stsp at users dot sourceforge.net
` (11 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-25 18:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Because without the -dD implicitly added for -g3 the -g3 option can't work as
documented, in particular record the macros in the debug information. Because
they would be irrecoverably lost during the preprocessing phase.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (12 preceding siblings ...)
2020-11-25 18:14 ` jakub at gcc dot gnu.org
@ 2020-11-25 18:22 ` stsp at users dot sourceforge.net
2020-11-25 18:28 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-25 18:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #14 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Jakub Jelinek from comment #13)
> Because without the -dD implicitly added for -g3 the -g3 option can't work
> as documented, in particular record the macros in the debug information.
> Because they would be irrecoverably lost during the preprocessing phase.
I think there is a bit of misunderstanding.
The question is:
I re-checked and found that not only "gcc -g3"
sets -dD for cpp (which I understand), but also
"cpp -g3" does the same. Raw cpp, not gcc.
Should cpp react on -gX directly, rather than
on an implicitly set -dD?
But:
$ gcc -Wp,-g3 -E -Wp,-P -xc - </dev/null
doesn't produce any output... confused.
$ cpp -g3 -P -xc -g0 - </dev/null
shouldn't produce anyothing, or?
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (13 preceding siblings ...)
2020-11-25 18:22 ` stsp at users dot sourceforge.net
@ 2020-11-25 18:28 ` jakub at gcc dot gnu.org
2020-11-26 12:02 ` stsp at users dot sourceforge.net
` (9 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-25 18:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
cpp is just a different name of the same driver that defaults to -E, nothing
else. -Wp,-g3 doesn't really do anything, because -g* aren't preprocessor
options, it is a driver option (where driver among other transforms some -g*
options to -dD for the preprocessor) and a compiler option.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (14 preceding siblings ...)
2020-11-25 18:28 ` jakub at gcc dot gnu.org
@ 2020-11-26 12:02 ` stsp at users dot sourceforge.net
2020-11-26 12:09 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-26 12:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #16 from Stas Sergeev <stsp at users dot sourceforge.net> ---
What do you think about, in addition
to your current patch, to also change
-P to disable debug?
Looks more user-friendly and clang-compatible?
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (15 preceding siblings ...)
2020-11-26 12:02 ` stsp at users dot sourceforge.net
@ 2020-11-26 12:09 ` jakub at gcc dot gnu.org
2020-11-26 12:34 ` stsp at users dot sourceforge.net
` (7 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-26 12:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Looks like a bad idea to me. And, I think gcc had this behavior for -g3 and -P
years before clang implemented those, so arguing here about clang-compatibility
is strange. clang simply decided not to implement the documented switches the
way they were documented.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (16 preceding siblings ...)
2020-11-26 12:09 ` jakub at gcc dot gnu.org
@ 2020-11-26 12:34 ` stsp at users dot sourceforge.net
2020-11-26 12:53 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-26 12:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #18 from Stas Sergeev <stsp at users dot sourceforge.net> ---
IMHO the only thing that makes sense,
is whether or not this is useful in practice.
If there are no practical cases for current
"-g3 -P" behaviour, then to me the fact that
its documented that way, is more or less irrelevant. :)
Besides, not every extension contradicts the
documentation. If you extend -P that way, it
will still suppress the line numbers, perfectly
as documented before, so no old use-cases are
supposed to be broken.
> clang simply decided not to implement the documented
> switches the way they were documented.
But in a way that is most useful in practice. :)
But whatever.
I know such arguments (practical use vs documentation)
were raised 1024+ times here, so not trying to say
something new.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (17 preceding siblings ...)
2020-11-26 12:34 ` stsp at users dot sourceforge.net
@ 2020-11-26 12:53 ` jakub at gcc dot gnu.org
2020-11-26 13:40 ` stsp at users dot sourceforge.net
` (5 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-26 12:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, clang like gcc documents -P to only disable line markers, and it is also
what that option does in clang.
Just try clang -dD -E -P, it will show the #define lines all over too.
It is just that clang doesn't support -g3 at all, as can be seen by clang not
producing any .debug_macinfo nor .debug_macro sections.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (18 preceding siblings ...)
2020-11-26 12:53 ` jakub at gcc dot gnu.org
@ 2020-11-26 13:40 ` stsp at users dot sourceforge.net
2020-11-26 14:10 ` stsp at users dot sourceforge.net
` (4 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-26 13:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #20 from Stas Sergeev <stsp at users dot sourceforge.net> ---
Ah, makes sense, thank you.
I was always wondering why under clang I
need to do "-fdebug-macro" for that (which
makes problems for gcc as being an unknown option).
But "clang -g3 -fdebug-macro -E -Wp,-P - </dev/null"
still doesn't produce anything interesting,
so I wonder...
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (19 preceding siblings ...)
2020-11-26 13:40 ` stsp at users dot sourceforge.net
@ 2020-11-26 14:10 ` stsp at users dot sourceforge.net
2020-11-26 14:16 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-26 14:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #21 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Jakub Jelinek from comment #19)
> It is just that clang doesn't support -g3 at all, as can be seen by clang
> not producing any .debug_macinfo nor .debug_macro sections.
So with -fdebug-macro it actually produces
.debug_macinfo, but still no .debug_macro.
Yet gdb is quite happy with that and can see
the macros.
So...
Why "clang -g3 -fdebug-macro -E -Wp,-P - </dev/null"
doesn't produce anything on screen??
So it works perfectly!
But I don't know how. :)
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (20 preceding siblings ...)
2020-11-26 14:10 ` stsp at users dot sourceforge.net
@ 2020-11-26 14:16 ` jakub at gcc dot gnu.org
2020-11-26 14:30 ` stsp at users dot sourceforge.net
` (2 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-26 14:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Stas Sergeev from comment #21)
> (In reply to Jakub Jelinek from comment #19)
> > It is just that clang doesn't support -g3 at all, as can be seen by clang
> > not producing any .debug_macinfo nor .debug_macro sections.
>
> So with -fdebug-macro it actually produces
> .debug_macinfo, but still no .debug_macro.
> Yet gdb is quite happy with that and can see
> the macros.
>
> So...
> Why "clang -g3 -fdebug-macro -E -Wp,-P - </dev/null"
> doesn't produce anything on screen??
> So it works perfectly!
> But I don't know how. :)
Because it doesn't bother trying to preserve the macros across separate
preprocessing. So while clang -g3 -fdebug-macro -S can work,
doing clang -g3 -fdebug-macro -E -o test.i test.c; clang -g3 -fdebug-macro -S
-fpreprocessed test.i will not work (something e.g. ccache usually does).
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (21 preceding siblings ...)
2020-11-26 14:16 ` jakub at gcc dot gnu.org
@ 2020-11-26 14:30 ` stsp at users dot sourceforge.net
2020-12-01 8:40 ` cvs-commit at gcc dot gnu.org
2020-12-01 9:15 ` jakub at gcc dot gnu.org
24 siblings, 0 replies; 26+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-26 14:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #23 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Jakub Jelinek from comment #22)
> -S -fpreprocessed test.i will not work
It doesn't seem to support -fpreprocessed though.
Thanks for explanations and sorry about
naively attributing that effect to -P.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (22 preceding siblings ...)
2020-11-26 14:30 ` stsp at users dot sourceforge.net
@ 2020-12-01 8:40 ` cvs-commit at gcc dot gnu.org
2020-12-01 9:15 ` jakub at gcc dot gnu.org
24 siblings, 0 replies; 26+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-12-01 8:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #24 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:934a54180541d27139aecbd19e7f50cb73552c7c
commit r11-5596-g934a54180541d27139aecbd19e7f50cb73552c7c
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Dec 1 09:39:04 2020 +0100
driver: Don't imply -dD for -g3 -g0 [PR97989]
The driver enables -dD when preprocessing when -g3 is specified, for
obvious reasons
that we need the macros to be preserved somewhere for them to make up the
debug
info. But it enables it even if -g3 is later overridden to -g2, -g1 or
-g0,
where we in the end don't emit .debug_mac{ros,info}.
The following patch passes -dD only if we'll need it.
2020-12-01 Jakub Jelinek <jakub@redhat.com>
PR debug/97989
* gcc.c (cpp_unique_options): Add -dD if %:debug-level-gt(2)
rather than g3|ggdb3|gstabs3|gxcoff3|gvms3.
* gcc.dg/cpp/pr97989-1.c: New test.
* gcc.dg/cpp/pr97989-2.c: New test.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug debug/97989] -g3 somehow breaks -E
2020-11-25 16:21 [Bug debug/97989] New: -g3 somehow breaks -E stsp at users dot sourceforge.net
` (23 preceding siblings ...)
2020-12-01 8:40 ` cvs-commit at gcc dot gnu.org
@ 2020-12-01 9:15 ` jakub at gcc dot gnu.org
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-12-01 9:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |FIXED
--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 26+ messages in thread