This is the mail archive of the gcc@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: Compiler crash with block numbers


The bug is in tree-eh.c. IS_UNKNOWN_LOCATION is mistakenly used, thus
the block info for a call stmt is cleared.

A patch to fix the problem is atached:

gcc/ChangeLog:
        tree-eh.c (lower_try_finally_dup_block): Use correct way to
check unknown location.

Index: tree-eh.c
===================================================================
--- tree-eh.c	(revision 191494)
+++ tree-eh.c	(working copy)
@@ -883,7 +883,7 @@ lower_try_finally_dup_block (gimple_seq seq, struc
   new_seq = copy_gimple_seq_and_replace_locals (seq);

   for (gsi = gsi_start (new_seq); !gsi_end_p (gsi); gsi_next (&gsi))
-    if (IS_UNKNOWN_LOCATION (gimple_location (gsi_stmt (gsi))))
+    if (gimple_location (gsi_stmt (gsi)) == UNKNOWN_LOCATION)
       gimple_set_location (gsi_stmt (gsi), loc);

   if (outer_state->tf)

Is it ok for trunk?

Thanks,
Dehao

On Fri, Sep 21, 2012 at 3:47 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Sep 20, 2012 at 11:46 AM, Dehao Chen <dehao@google.com> wrote:
>> Sure, I'll look into this problem today.
>>
>> Thanks,
>> Dehao
>>
>> On Fri, Sep 21, 2012 at 2:25 AM, Ian Lance Taylor <iant@google.com> wrote:
>>> Hi Dehao, I suspect that your recent patch changing block handling has
>>> broken bootstrap with --enable-languages=go.  I reduced the test case
>>> to this C++ code:
>>>
>>> #include <string>
>>>
>>> std::string
>>> f(bool is_string, bool is_constant)
>>> {
>>>   if (is_string)
>>>     {
>>>       std::string left_string;
>>>       std::string right_string;
>>>       if (is_constant)
>>>         {
>>>           return left_string + right_string;
>>>         }
>>>     }
>>>
>>>   return "";
>>> }
>>>
>>> When I compile that with current mainline with -O -g I get a crash
>>> (the backtrace is a local patch of mine):
>>>
>>> foo.cc: In function ‘std::string f(bool, bool)’:
>>> foo.cc:17:1: internal compiler error: tree check: expected block, have
>>> function_decl in change_scope, at final.c:1544
>>>  }
>>>  ^
>>> 0xe388bd tree_check_failed(tree_node const*, char const*, int, char const*, ...)
>>>         ../../trunk/gcc/tree.c:8892
>>> 0x50c495 tree_check(tree_node*, char const*, int, char const*, tree_code)
>>>         ../../trunk/gcc/tree.h:3659
>>> 0x9372a1 change_scope
>>>         ../../trunk/gcc/final.c:1544
>>> 0x937646 reemit_insn_block_notes
>>>         ../../trunk/gcc/final.c:1613
>>> 0x937822 final_start_function(rtx_def*, _IO_FILE*, int)
>>>         ../../trunk/gcc/final.c:1670
>>> 0x93c6ad rest_of_handle_final
>>>         ../../trunk/gcc/final.c:4291
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> Please include the complete backtrace with any bug report.
>>> See <http://gcc.gnu.org/bugs.html> for instructions.
>>>
>>>
>>> At first glance the bug is that the block obtained from insn_scope
>>> (insn), called from reemit_insn_block_notes, has a block number of 0.
>>> That leads to the crash in insn_scope.
>>>
>>> It's interesting that it only occurs with -g.  I'm not sure what that means.
>>>
>>> Could you take a look at this and see if it is due to your patch?
>>>
>>> Thanks.
>>>
>>> Ian
>
> It may also cause:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645
>
> --
> H.J.


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