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] Prevent 'control reaches end of non-void function' warning for DO_WHILE


On Fri, Dec 9, 2011 at 9:38 AM, Tom de Vries <Tom_deVries@mentor.com> wrote:
> Jakub,
>
> This patch fixes the problem reported in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25973#c4 .
>
> The test-case listed there is:
> ...
> struct Block
> {
> ?public:
> ? ?Block();
> ? ?~Block();
> };
>
> bool func( bool bar )
> {
> ?Block block;
> ?bool foo = false;
>
> ?if( !foo || bar )
> ? ?do { return true; } while( 0 );
> ?else
> ? ?do { return false; } while( 0 );
> }
> ...
>
> For O0, a spurious warning is generated:
> ...
> $ gcc -O0 -Wreturn-type block.C -S:
> block.C: In function ‘bool func(bool)’:
> block.C:17:1: warning: control reaches end of non-void function [-Wreturn-type]
> ...
>
> Basically the patch tries to handle DO_STMT in block_may_fallthru, but since
> it's a cp-tree.def tree, it's done via a language hook.
>
> Improving block_may_fallthru helps code in gimplify.c:shortcut_cond_expr() to
> prevent the superfluous warning:
> ...
> ?/* We only emit the jump over the else clause if we have to--if the
> ? ? then clause may fall through. ?Otherwise we can wind up with a
> ? ? useless jump and a useless label at the end of gimplified code,
> ? ? which will cause us to think that this conditional as a whole
> ? ? falls through even if it doesn't. ?If we then inline a function
> ? ? which ends with such a condition, that can cause us to issue an
> ? ? inappropriate warning about control reaching the end of a
> ? ? non-void function. ?*/
> ?jump_over_else = block_may_fallthru (then_);
> ...
>
> Bootstrapped and reg-tested on x86_64.
>
> OK for next stage1?

Hm.  I would prefer if the gimplifier is fed GENERIC, not
GENERIC plus FE specific codes ... (both C and C++ do
"genericization" passes, but they actually do not transform
all code to GENERIC).  Can you check if it's easy enough to
lower DO_STMT during cp_genericize?

Thanks,
Richard.

> Thanks,
> - Tom
>


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