Re: classmap.db build fail does not fail libjava build

[Richard Guenther <rguenther at suse dot de>]

On Wed, 5 Sep 2007, Andrew Haley wrote:

>  > It looks like a segfault in
>  > 
>  > 0x00002af3a85f54a2 in _ZN4java4lang11ClassLoader18__U3c_clinit__U3e_EJvv 
>  > ()
>  >     at /abuild/rguenther/trunk/libjava/java/lang/ClassLoader.java:284
>  > 284         PermissionCollection perm = Policy.getPolicy().getPermissions(cs);
>  > 
>  > of course I have no idea how to debug this ;)
> 
> Perhaps Policy.getPolicy() is returning null.  This ought to be
> impossible, but perhaps something in Policy is being miscompiled.  In
> any case, it should be easy enough to see where your patch changes the
> generated code.

It looks like in classpath/java/security/Policy.java getCurrentPolicy()
we take the path to

        if (currentPolicy == null)
          currentPolicy = new gnu.java.security.provider.DefaultPolicy();

but return the wrong value:

0x00002b1d69cdd4cd 
<_ZN4java8security6Policy16getCurrentPolicyEJPS1_v+125>:     callq  
0x2b1d6985c8e0 <_Jv_AllocObjectNoFinalizer@plt>
0x00002b1d69cdd4d2 
<_ZN4java8security6Policy16getCurrentPolicyEJPS1_v+130>:     mov    
%rax,%rbx
---Type <return> to continue, or q <return> to quit---
0x00002b1d69cdd4d5 
<_ZN4java8security6Policy16getCurrentPolicyEJPS1_v+133>:     mov    
%rax,%rdi
0x00002b1d69cdd4d8 
<_ZN4java8security6Policy16getCurrentPolicyEJPS1_v+136>:     callq  
0x2b1d69860080 <_ZN3gnu4java8security8provider13DefaultPolicyC1Ev@plt>
0x00002b1d69cdd4dd 
<_ZN4java8security6Policy16getCurrentPolicyEJPS1_v+141>:     mov    
%rbx,20349996(%rip)        # 0x2b1d6b045910 
<_ZN4java8security6Policy13currentPolicyE>
0x00002b1d69cdd4e4 
<_ZN4java8security6Policy16getCurrentPolicyEJPS1_v+148>:     jmp    
0x2b1d69cdd479 <_ZN4java8security6Policy16getCurrentPolicyEJPS1_v+41>

...

0x00002b1d69cdd479 <_ZN4java8security6Policy16getCurrentPolicyEJPS1_v+41>:      
mov    %rbp,%rax
---Type <return> to continue, or q <return> to quit---
0x00002b1d69cdd47c <_ZN4java8security6Policy16getCurrentPolicyEJPS1_v+44>:      
mov    0x8(%rsp),%rbx
0x00002b1d69cdd481 <_ZN4java8security6Policy16getCurrentPolicyEJPS1_v+49>:      
mov    0x10(%rsp),%rbp
0x00002b1d69cdd486 <_ZN4java8security6Policy16getCurrentPolicyEJPS1_v+54>:      
add    $0x18,%rsp
0x00002b1d69cdd48a <_ZN4java8security6Policy16getCurrentPolicyEJPS1_v+58>:      
retq   

(%rbp is null, %rbx is ok)


FRE with the patch changes

  # VUSE <currentPolicy_49>
  D.2213_43 = currentPolicy;
  #ref#1#1_44 = D.2213_43;
  D.2231_45 = (struct  *) #ref#1#1_44;
  return D.2231_45;

to

  # VUSE <currentPolicy_49>
  D.2213_43 = currentPolicy;
  #ref#1#1_44 = D.2213_43;
  D.2231_45 = #ref#1#1.227_5;
  return D.2231_45;

because we have

  # VUSE <currentPolicy_84>
  D.2154_3 = currentPolicy;
  #ref#1#1_4 = D.2154_3;
  #ref#1#1.227_5 = (struct  *) #ref#1#1_4;
  if (#ref#1#1.227_5 != 0B)

and with the FRE patch we get things like

Value numbering D.2213_43 stmt = D.2213_43 = currentPolicy;
Setting value number of D.2213_43 to D.2213_43
SCC consists of: #ref#1#1_44
Value numbering #ref#1#1_44 stmt = #ref#1#1_44 = D.2213_43;
Setting value number of #ref#1#1_44 to D.2213_43
SCC consists of: D.2231_45
Value numbering D.2231_45 stmt = D.2231_45 = (struct  *) #ref#1#1_44;
RHS (struct  *) #ref#1#1_44 simplified to currentPolicy has constants 0

so it changes a conversion of an SSA_NAME to a load!  Do I have to
guard against this or how can I make this correct?

For the binary simplification case we also don't seem to guard for
this case.

Unfortunately I failed to do a C testcase.  Modifying the FRE patch
to check like

  result = fold_unary (TREE_CODE (rhs), TREE_TYPE (rhs), op0);
  if (result
      && (TREE_CODE (result) == SSA_NAME
          || is_gimple_min_invariant (result)))
    {
      STRIP_USELESS_TYPE_CONVERSION (result);
      if (valid_gimple_expression_p (result))
        return result;

makes it work.  In which cases do I need to call valueize_expr?

Thanks for clarification,
Richard.