public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/70270] Spurious line directive with -g Date: Sun, 19 Dec 2021 09:50:00 +0000 [thread overview] Message-ID: <bug-70270-4-dcMpFQC2Ck@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-70270-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70270 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|preprocessor |c --- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> --- This actually coming from the C/C++ common part of the front-end and not from the preprocessor: void pp_dir_change (cpp_reader *pfile ATTRIBUTE_UNUSED, const char *dir) { size_t to_file_len = strlen (dir); unsigned char *to_file_quoted = (unsigned char *) alloca (to_file_len * 4 + 1); unsigned char *p; /* cpp_quote_string does not nul-terminate, so we have to do it ourselves. */ p = cpp_quote_string (to_file_quoted, (const unsigned char *) dir, to_file_len); *p = '\0'; fprintf (print.outf, "# 1 \"%s//\"\n", to_file_quoted); } And when read back in it invokes cb_dir_change: cb->dir_change = cb_dir_change; ... void cb_dir_change (cpp_reader * ARG_UNUSED (pfile), const char *dir) { if (!set_src_pwd (dir)) warning (0, "too late for # directive to set debug directory"); } So I don't think it changes the different line-map behavior at all. The first two lines are special in the preprocessed source for libcpp: /* For preprocessed files, if the very first characters are '#<SPACE>[01]<SPACE>', then handle a line directive so we know the original file name. This will generate file_change callbacks, which the front ends must handle appropriately given their state of initialization. We peek directly into the character buffer, so that we're not confused by otherwise-skipped white space & comments. We can be very picky, because this should have been machine-generated text (by us, no less). This way we do not interfere with the module directive state machine. */ .... /* For preprocessed files, if the tokens following the first filename line is of the form # <line> "/path/name//", handle the directive so we know the original current directory. As with the first line peeking, we can do this without lexing by being picky. */ So I don't think the line mapping changes at all with this.
parent reply other threads:[~2021-12-19 9:50 UTC|newest] Thread overview: expand[flat|nested] mbox.gz Atom feed [parent not found: <bug-70270-4@http.gcc.gnu.org/bugzilla/>]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-70270-4-dcMpFQC2Ck@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).