This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR17544, a C99 and C++ Wunreachable-code problem


On Friday 31 December 2004 14:21, Gabriel Dos Reis wrote:
> Steven Bosscher <stevenb@suse.de> writes:
> | Hi,
> |
> | This patch is marked "middle-end", but really it's a problem in the
> | middle-end *and* the front ends.  There was no way to mark a complete
> | statement as compiler generated in a way that would survive through
> | gimplification, and the gimplifier would notice that some statements
> | do not have a source location.
> |
> | In this particular case, the "return 0;" statement required in C99
> | mode and by C++ would get annotated with a locus by the gimplifier.
> |
> | But often the compiler generated "return 0;" is not reachable.  The
> | -Wunreachable-code warnings only happen for statements with a source
> | location, and since the compiler generated statement got a locus in
> | the gimplifier, we warn if they're unreachable.
> |
> | My proposed fix is to put a locus on the compiler generated statement
> | in the front end: just put it in the current file, on line 0.  Then
> | teach the places where we issue unreachable code warnings to issue
> | the warning only if the unreachable code is on a line number >0.
> |
> | The attached patch was bootstrapped and tested (all except Ada) on
> | x86_64-suse-linux-gnu, and it fixes PR17544, a regression from all
> | earlier GCC releases.  OK to apply?
>
> Here is an alternative way to that.  Look for one of the unused flag
> in tree_common, for statements.  Choices are
>
>    private_flag
>    unsigned_flag
>    nothrow_flag
>    deprecated_flag
>
> Alternatively, you can set TREE_NO_WARNING (which I would think much
> cleaner).

Maybe you didn't read the first paragraph of my first mail, so I'll
repeat:

"There was no way to mark a complete statement as compiler generated
in a way that would survive through gimplification"

If you set TREE_NO_WARNING, after gimplification, you *still* have a
locus and your flag setting is gone.  I agree it would be much cleaner,
but you would have to modify the gimplifier everywhere to preserve the
flag, teach tree modifying functions all over to do the same, etc.
Just making line 0 a special line seems much simpler.

Gr.
Steven



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]