On 07/25/2017 01:55 PM, Richard Biener wrote:
> 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?
No, following simple test-case can break it:
$ cat ice.i
__attribute__ ((__always_inline__)) int a ()
{
int b = 0;
}
void
c ()
{
a ();
}
Thus maybe a small adjustment of the comment can be done.
>
>> 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.
Yep, I just mean comment which says that we do such transformation just
because of Java. Which is probably not true I guess.
>
> 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
For the rest, I've been testing patch.
Martin
