Re: PR 20505

[James E Wilson <wilson at specifixinc dot com>]

Nathan Sidwell wrote:
> Bug 20505 is an ICE with -ggdb2.  We have the following member
> definition,
>   const int b::d = ((int)(&((b*)1)->c) - 1);
> whose initializer used to be folded during construction to an INT_CST, but
> now it doesn't -- fold cannot fold the complete expression.  As

> My inclination is to simply add an additional check in the dwarf outputter,
> verifying that the initializer is indeed an INT_CST.

That is a simple solution, but it causes us to lose debug info.

Looking at output_constant in varasm.c, I see that it works because it 
calls expand_expr to convert the initializer to RTL, and then emits the 
constant RTL.  We can solve the dwarf2out.c problem similarly.  That 
suggests a patch like the attached untested patch.  This simplifies the 
code, retains the debug info for this case, and even emits debug info 
for some cases like const FP vars that we currently don't handle.  There 
is the drawback that we might hit an abort for unexpected cases, whereas 
the current code just does nothing.  If it is important to avoid this on 
the gcc-4.0 branch, we could just add the expand_expr call, and then use 
INTVAL and CONST_DOUBLE_{LOW,HIGH} instead of tree_low_cst and 
TREE_INT_CST_{LOW,HIGH}.  That should be safe.  On mainline, I think we 
should try supporting everything here and see what happens.

Looking at this further, I find it interesting that 
tree_add_const_value_attribute is only called from one place in an else 
stmt.  The if stmt calls add_const_value_attribute.  Following that, I 
see that if we have a variable with no DECL_RTL but with a DECL_INITIAL, 
then the exact same thing happens as what my patch does.  We call 
expand_expr to generate constant rtl.  This happens in 
rtl_for_decl_location.  There is a check for INTEGER_CST and REAL_CST on 
this path, but these aren't strictly necessary, and are now undesirable 
if the front ends aren't simplifying constants for us as is the case 
here.  This seems to imply that my solution is the right approach, and 
that other simplifications and bug fixes may be possible or desirable 
here, but one problem at a time...
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
2005-03-29  James E Wilson  <wilson@specifixinc.com>

	* dwarf2out.c (tree_add_const_value_attribute):  Call expand_expr
	and add_const_value_attribute.

Index: dwarf2out.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
retrieving revision 1.574
diff -p -p -r1.574 dwarf2out.c
*** dwarf2out.c	22 Mar 2005 23:18:42 -0000	1.574
--- dwarf2out.c	30 Mar 2005 01:49:07 -0000
*************** tree_add_const_value_attribute (dw_die_r
*** 10130,10149 ****
    else
      return;
  
!   switch (TREE_CODE (type))
!     {
!     case INTEGER_TYPE:
!       if (host_integerp (init, 0))
! 	add_AT_unsigned (var_die, DW_AT_const_value,
! 			 tree_low_cst (init, 0));
!       else
! 	add_AT_long_long (var_die, DW_AT_const_value,
! 			  TREE_INT_CST_HIGH (init),
! 			  TREE_INT_CST_LOW (init));
!       break;
! 
!     default:;
!     }
  }
  
  /* Generate a DW_AT_name attribute given some string value to be included as
--- 10130,10137 ----
    else
      return;
  
!   add_const_value_attribute (var_die, expand_expr (init, NULL_RTX, VOIDmode,
! 						   EXPAND_INITIALIZER));
  }
  
  /* Generate a DW_AT_name attribute given some string value to be included as