https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #24 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:934a54180541d27139aecbd19e7f50cb73552c7c
commit r11-5596-g934a54180541d27139aecbd19e7f50cb73552c7c
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #23 from Stas Sergeev ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #22 from Jakub Jelinek ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #21 from Stas Sergeev ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #20 from Stas Sergeev ---
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 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #19 from Jakub Jelinek ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #18 from Stas Sergeev ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #17 from Jakub Jelinek ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #16 from Stas Sergeev ---
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #15 from Jakub Jelinek ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #14 from Stas Sergeev ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #13 from Jakub Jelinek ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #12 from Stas Sergeev ---
Will your patch also fix this:
$ cpp -g3 -P -xc -g0 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-11-25
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #10 from Stas Sergeev ---
Ah, cool, thanks.
Should this be re-opened?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #9 from Jakub Jelinek ---
It will allow -g0 at the end to override the earlier -g3 and not add -dD in
that case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #8 from Stas Sergeev ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #7 from Jakub Jelinek ---
Created attachment 49627
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49627=edit
gcc11-pr97989.patch
That can be handled by this patch. But we can't retroactively apply it to
released versions (and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #6 from Stas Sergeev ---
(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.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #5 from Jakub Jelinek ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #4 from Stas Sergeev ---
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!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #3 from Jakub Jelinek ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
25 matches
Mail list logo
