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]

[RFC] Remaining references of Java


Hi.

There's a small follow-up with remaining occurrences:

1) dwarf2out.c:

 20213	    origin_die = lookup_type_die (origin);
 20214	  else if (TREE_CODE (origin) == BLOCK)
 20215	    origin_die = BLOCK_DIE (origin);
 20216	
 20217	  /* XXX: Functions that are never lowered don't always have correct block
 20218	     trees (in the case of java, they simply have no block tree, in some other
 20219	     languages).  For these functions, there is nothing we can really do to
 20220	     output correct debug info for inlined functions in all cases.  Rather
 20221	     than die, we'll just produce deficient debug info now, in that we will
 20222	     have variables without a proper abstract origin.  In the future, when all
 20223	     functions are lowered, we should re-add a gcc_assert (origin_die)

Probably Jakub can help with that?

2) fold-const.c:

  1882	  /* The following code implements the floating point to integer
  1883	     conversion rules required by the Java Language Specification,
  1884	     that IEEE NaNs are mapped to zero and values that overflow
  1885	     the target precision saturate, i.e. values greater than
  1886	     INT_MAX are mapped to INT_MAX, and values less than INT_MIN
  1887	     are mapped to INT_MIN.  These semantics are allowed by the
  1888	     C and C++ standards that simply state that the behavior of
  1889	     FP-to-integer conversion is unspecified upon overflow.  */
  1890	
  1891	  wide_int val;
  1892	  REAL_VALUE_TYPE r;
  1893	  REAL_VALUE_TYPE x = TREE_REAL_CST (arg1);

Can we somehow remove that Richi?

3) gimplify.c:

  2771	     Java requires that we elaborated nodes in source order.  That
  2772	     means we must gimplify the inner expression followed by each of
  2773	     the indices, in order.  But we can't gimplify the inner
  2774	     expression until we deal with any variable bounds, sizes, or
  2775	     positions in order to deal with PLACEHOLDER_EXPRs.
  2776	
  2777	     So we do this in three steps.  First we deal with the annotations
  2778	     for any variables in the components, then we gimplify the base,
  2779	     then we gimplify any indices, from left to right.  */
  2780	  for (i = expr_stack.length () - 1; i >= 0; i--)

Richi?

4) tree.c:

 13535	  if (RECORD_OR_UNION_TYPE_P (t) && TYPE_BINFO (t) && TYPE_BINFO (tv)
 13536	      && TYPE_BINFO (t) != TYPE_BINFO (tv)
 13537	      /* FIXME: Java sometimes keep dump TYPE_BINFOs on variant types.
 13538		 Since there is no cheap way to tell C++/Java type w/o LTO, do checking
 13539		 at LTO time only.  */
 13540	      && (in_lto_p && odr_type_p (t)))
 13541	    {
 13542	      error ("type variant has different TYPE_BINFO");
 13543	      debug_tree (tv);
 13544	      error ("type variant's TYPE_BINFO");
 13545	      debug_tree (TYPE_BINFO (tv));
 13546	      error ("type's TYPE_BINFO");
 13547	      debug_tree (TYPE_BINFO (t));
 13548	      return false;

Can we Honza remove that?

Thanks,
Martin


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