Re: [RFC] Remaining references of Java

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Jul 11, 2017 at 4:35 PM, Martin Liška <mliska@suse.cz> wrote:
> 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?

Can you check whether all-language bootstrap passes with the suggested
gcc_assert?

> 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?

Remove what?  The comment?  It still matches the code and we have to
do sth.  So I don't see why we should change this.

Maybe Joseph knows whether future standards / TRs recommend sth different
or exactly this.

>
> 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?

Just change the comment to "We elaborate nodes in source order. [...]"

> 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?

Try it? (remove in_lto_p &&)

> Thanks,
> Martin