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