Tree checking failure in jc1

Dave Korn <[email protected]>
Newsgroups gmane.comp.gcc.java.devel,gmane.comp.gcc.devel
Message-ID <[email protected]>
    Hi lists,

  I found a couple of new FAILs in my latest libjava testrun:

> FAIL: newarray_overflow -O3 compilation from source
> FAIL: newarray_overflow -O3 -findirect-dispatch compilation from source

  These turn out to be tree checking failures:

> In file included from <built-in>:3:0:
> newarray_overflow.java:20:0: internal compiler error: tree check: expected class
>  'type', have 'declaration' (function_decl) in put_decl_node, at java/lang.c:405

... happening ...

> /* Append to decl_buf a printable name for NODE.
>    Depending on VERBOSITY, more information about NODE
>    is printed. Read the comments of decl_printable_name in
>    langhooks.h for more.  */
> 
> static void
> put_decl_node (tree node, int verbosity)
> {
>   int was_pointer = 0;
>   if (TREE_CODE (node) == POINTER_TYPE)
>     {
>       node = TREE_TYPE (node);
>       was_pointer = 1;
>     }
>   if (DECL_P (node) && DECL_NAME (node) != NULL_TREE)
>     {
>       if (TREE_CODE (node) == FUNCTION_DECL)
> 	{
> 	  if (verbosity == 0 && DECL_NAME (node))
> 	  /* We have been instructed to just print the bare name
> 	     of the function.  */
> 	    {
> 	      put_decl_node (DECL_NAME (node), 0);
> 	      return;
> 	    }
> 
> 	  /* We want to print the type the DECL belongs to. We don't do
> 	     that when we handle constructors. */
> 	  if (! DECL_CONSTRUCTOR_P (node)
> 	      && ! DECL_ARTIFICIAL (node) && DECL_CONTEXT (node)
>               /* We want to print qualified DECL names only
>                  if verbosity is higher than 1.  */
>               && verbosity >= 1)
> 	    {
> 	      put_decl_node (TYPE_NAME (DECL_CONTEXT (node)),
>                                verbosity);
 ... here:    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  The decl pointed to by 'node' is a function_decl for a builtin:

 <function_decl 0x7ff8f580 __builtin_prefetch
    type <function_type 0x7fe52ee0
        type <void_type 0x7ff608a0 void asm_written VOID
            align 1 symtab 0 alias set -1 canonical type 0x7ff608a0
            pointer_to_this <pointer_type 0x7ff60900> chain <type_decl
0x7fdd0380 void>>
        QI
        size <integer_cst 0x7fef0108 constant 8>
        unit size <integer_cst 0x7fef0120 constant 1>
        align 8 symtab 0 alias set -1 canonical type 0x7fe52ee0
        arg-types <tree_list 0x7feff138 value <pointer_type 0x7ff609c0>
            chain <tree_list 0x7fef0b10 value <void_type 0x7ff608a0 void>>>
        pointer_to_this <pointer_type 0x7fe53000>>
    addressable public external built-in QI file <built-in> line 0 col 0
    align 8 built-in BUILT_IN_NORMAL:BUILT_IN_PREFETCH context <function_decl
0x7ff82b80 int_check> chain <var_decl 0x7fe2f900 _Utf15>>

and the DECL_CONTEXT turns out to be another function, one present in the
source of the testcase:

 <function_decl 0x7ff82b80 int_check
    type <function_type 0x7ff648c0
        type <void_type 0x7ff608a0 void asm_written VOID
            align 1 symtab 0 alias set -1 canonical type 0x7ff608a0
            pointer_to_this <pointer_type 0x7ff60900> chain <type_decl
0x7fdd0380 void>>
        QI
        size <integer_cst 0x7fef0108 constant 8>
        unit size <integer_cst 0x7fef0120 constant 1>
        align 8 symtab 0 alias set -1 canonical type 0x7ff648c0
        arg-types <tree_list 0x7fef0b10 value <void_type 0x7ff608a0 void>>
        pointer_to_this <pointer_type 0x7fe27140>>
    addressable public decl_2 QI file newarray_overflow.java line 20 col 0
align 8 context <record_type 0x7ff65520 newarray_overflow> initial <block
0x7fde6af8>
    result <result_decl 0x7fe100a0 D.246 type <void_type 0x7ff608a0 void>
        ignored VOID file newarray_overflow.java line 0 col 0
        align 1 context <function_decl 0x7ff82b80 int_check>>
    struct-function 0x7ff98df8 chain <function_decl 0x7ff82c00 object_check>>

... which is why the TYPE_NAME macro complains.

  Is it expected for a builtin to appear as if it were a nested function like
this?  If so, would it make sense to do something like replace this:

	      put_decl_node (TYPE_NAME (DECL_CONTEXT (node)),
                               verbosity);

with:

	      put_decl_node (TREE_CODE (DECL_CONTEXT (node)) == FUNCTION_DECL
                               ? DECL_CONTEXT (node)
                               : TYPE_NAME (DECL_CONTEXT (node)),
                               verbosity);

so we just treat the builtin as another layer of scope?

    cheers,
      DaveK
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.