This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: "Herman, Andrei" <Andrei_Herman at codesourcery dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "Herman_Andrei at mentor dot com" <Herman_Andrei at relay1 dot mentorg dot com>
- Date: Wed, 7 May 2014 18:00:59 +0000
- Subject: Re: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option
- Authentication-results: sourceware.org; auth=none
- References: <FEC4CADEDABC9E40A1EC17465AAC8402AE41BF45 at EU-MBX-04 dot mgc dot mentorg dot com>
On Wed, 7 May 2014, Herman, Andrei wrote:
> When this flag is set, a DW_TAG_lexical_block DIE will be emitted 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 labeled
> 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.
> Consequently, any case in a switch statement that does not flow through to
> the next case, will have its own dwarf lexical block.
The documentation appears to suggest it's purely about debug info and has
no effect on language semantics. However, the implementation appears to
force C99 scoping rules. I don't think it's appropriate for a debug info
option to have that effect; that is, gcc.dg/c90-scope-1.c should still
pass even with the option enabled (more generally, the whole C testsuite
should be verified to work with the option enabled). I suspect the
changes adding scopes for labels would also affect language semantics;
it's valid in C to have a declaration (not having variably modified type)
after one case in a switch statement that gets used in another case even
when control does not flow through.
If you can't avoid affecting language semantics then you need to be very
clear in the documentation that the option makes some invalid programs
valid and vice versa and changes the semantics of some valid programs
(even if you then assert the affected cases are uncommon in real C code).
Joseph S. Myers