public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Joseph S. Myers" <joseph@codesourcery.com>
To: "Herman, Andrei" <Andrei_Herman@codesourcery.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	<Alex_Rozenman@mentor.com>
Subject: Re: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option
Date: Thu, 19 Jun 2014 21:09:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.64.1406192100530.2033@digraph.polyomino.org.uk> (raw)
In-Reply-To: <538B0151.5030404@codesourcery.com>

On Sun, 1 Jun 2014, Herman, Andrei wrote:

>+  /* The -fforce-dwarf-lexical-blocks option is only relevant when debug
>+     info is in DWARF4 format */
>+  if (flag_force_dwarf_blocks) {

Watch coding style: the opening '{' always goes on the next line.

>+fforce-dwarf-lexical-blocks
>+C C++ Var(flag_force_dwarf_blocks)
>+Force generation of lexical blocks in dwarf output

I don't see a good reason for this not to be supported for ObjC and ObjC++ 
as well.  Say DWARF, not dwarf.

>+@item -fforce-dwarf-lexical-blocks
>+Produce debug information (a DW_TAG_lexical_block) for every function
>+body, loop body, switch body, case statement, if-then and if-else statement,
>+even if the body is a single statement.  Likewise, a lexical block will be
>+emitted for the first label of a statement.  This block ends at the end of the
>+current lexical scope, or when a break, continue, goto or return statement is
>+encountered at the same lexical scope level.  This option is usefull for
>+coverage tools that utilize the dwarf debug information.
>+This option only applies to C/C++ code and is available when using DWARF
>+Version 4 or higher.

Use @code{} markup for keywords (if, else, break, continue, goto, return).  
"useful" not "usefull".  "DWARF" not "dwarf".

>+/* Create a block_loc struct for a statement list created on behalf of
>+   flag_force_dwarf_blocks.  We use this for label or forced c99 scopes.  */
>+
>+void
>+push_block_info (tree block, location_t loc, bool is_label)
>+{
>+  if (TREE_CODE(block) != STATEMENT_LIST)

Watch coding style: space before '(' in function and macro calls (and 
similar calls such as sizeof) (many places in this patch, not just this 
one).

>+tree
>+pop_block_info (location_t &loc)

It's not documented in codingconventions.html, but I think it's preferred 
to avoid returning values through reference arguments (see e.g. 
<https://gcc.gnu.org/ml/gcc-patches/2013-11/msg00198.html>).

>+{
>+  block_loc  tl = NULL;

Excess space between "block_loc" and "tl".

>@@ -4679,7 +4712,7 @@ c_parser_compound_statement_nostart (c_parser *parser)
>    expressions being rejected later.  */
> 
> static void
>-c_parser_label (c_parser *parser)
>+c_parser_label (c_parser *parser, bool prev_label)

You're adding a new argument - you need to update the comment above this 
function to explain the semantics of this argument.

In general, make sure that new functions have comments above them that 
explain the semantics of the arguments (by name) and any return value.

>+/* If current scope is a label scope, pop it from block info stack
>+   and close it's compound statement.  */

"its" not "it's".

-- 
Joseph S. Myers
joseph@codesourcery.com

  reply	other threads:[~2014-06-19 21:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-01 10:33 Herman, Andrei
2014-06-19 21:09 ` Joseph S. Myers [this message]
2014-06-21 17:06   ` Herman, Andrei
2014-07-28 13:50   ` Herman, Andrei
2014-08-14 21:14     ` Joseph S. Myers
  -- strict thread matches above, loose matches on Subject: below --
2014-05-07  9:32 Herman, Andrei
2014-05-07  9:36 ` pinskia
2014-05-07  9:43   ` Herman, Andrei
2014-05-07 15:59 ` Mike Stump
2014-05-07 17:19   ` Herman, Andrei
2014-05-07 17:25     ` Andrew Pinski
2014-05-07 18:01     ` Mike Stump
2014-05-07 18:01 ` Joseph S. Myers
2014-05-08 14:57   ` Herman, Andrei
2014-05-08 17:26     ` Joseph S. Myers
2014-05-08 17:44       ` Herman, Andrei
2014-05-08 21:01         ` Joseph S. Myers

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=Pine.LNX.4.64.1406192100530.2033@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=Alex_Rozenman@mentor.com \
    --cc=Andrei_Herman@codesourcery.com \
    --cc=gcc-patches@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: link
Be 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).