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] Fix PR 40445: C++ ICE when using __builtin_unreachable() as only statement in a function.


David Daney <ddaney@caviumnetworks.com> writes:

> Ian Lance Taylor wrote:
>> David Daney <ddaney@caviumnetworks.com> writes:
>>
>>> Index: cfgcleanup.c
>>> ===================================================================
>>> --- cfgcleanup.c	(revision 148867)
>>> +++ cfgcleanup.c	(working copy)
>>> @@ -1903,7 +1903,8 @@ try_optimize_cfg (int mode)
>>>  		  /* Note that forwarder_block_p true ensures that
>>>  		     there is a successor for this block.  */
>>>  		  && (single_succ_edge (b)->flags & EDGE_FALLTHRU)
>>> -		  && n_basic_blocks > NUM_FIXED_BLOCKS + 1)
>>> +		  && n_basic_blocks > NUM_FIXED_BLOCKS + 1
>>> +		  && single_pred_edge (b)->src != ENTRY_BLOCK_PTR)
>>
>> I don't see why this test is sufficient for what you are trying to
>> prevent.  It seems to me that this empty block could be followed by a
>> number of other blocks.
>>
>
> Let me try to explain the patch a little better.
>
> There are several parts of the rtl optimizers that cannot handle a
> function that contains zero basic blocks.  They include, but are not
> limited to: record_effective_endpoints and
> rest_of_handle_df_initialize.
>
> One approach would be to fix all of the issues related to such empty
> functions.  I considered doing that, but the patch was getting large,
> so I did this patch (which is admittedly a bit of a hack) instead.
>
> If we can prevent the first block of the function from being deleted,
> there will never be functions with zero basic blocks, and none of the
> related problems will be exposed.
>
> Certainly the empty first block could be followed by other non-empty
> blocks and the patch would prevent it from being removed.  But it is
> empty so no code results and the compiler output is not (in theory)
> changed.

I think I got all that, but why not simply also test whether the
successor block is the exit block?  If it isn't, then it should be fine
to go ahead and delete the block.  Shouldn't it?

Ian


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