public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/97989] New: -g3 somehow breaks -E
@ 2020-11-25 16:21 stsp at users dot sourceforge.net
  2020-11-25 16:27 ` [Bug debug/97989] " jakub at gcc dot gnu.org
                   ` (24 more replies)
  0 siblings, 25 replies; 26+ messages in thread
From: stsp at users dot sourceforge.net @ 2020-11-25 16:21 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989

            Bug ID: 97989
           Summary: -g3 somehow breaks -E
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

$ gcc -E -Wp,-P -xc - </dev/null

No output, correct.

$ gcc -g3 -E -Wp,-P -xc - </dev/null

Lots of cpp defines in output, incorrect.

$ clang -g3 -E -Wp,-P -xc - </dev/null

No output, correct.

AFAIK no "#define"s should be outputted by the
cpp pass. Quite the opposite, cpp should expand
them all. But with -g3 for some reason this doesn't
happen.

^ 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 ` 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

end of thread, other threads:[~2020-12-01  9:15 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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
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
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
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
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
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

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).