> On Thu, Jun 14, 2012 at 5:33 PM, Michael Matz wrote:
> > Hi,
> >
> > On Thu, 14 Jun 2012, Michael Matz wrote:
> >
> >> In any case, this patch is currently in regstrapping on x86-64. Okay if
> >> it passes (modulo changes for the above symtab_get_node() issue)?
> >
> > After discussion with Hon
Hi,
On Thu, 14 Jun 2012, Richard Guenther wrote:
> > Restarted regstrapping the thing on x86_64 again. Okay if that
> > passes?
>
> Ok.
>
> But I wonder how the symtab cannot be "ready" when we gimplify - after
> all we gimplify only from after cgraph_finalize_compilation_unit ...
"Ready" m
On Thu, Jun 14, 2012 at 5:33 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 14 Jun 2012, Michael Matz wrote:
>
>> In any case, this patch is currently in regstrapping on x86-64. Okay if
>> it passes (modulo changes for the above symtab_get_node() issue)?
>
> After discussion with Honza, consider the p
> Hi,
>
> On Thu, 14 Jun 2012, Michael Matz wrote:
>
> > In any case, this patch is currently in regstrapping on x86-64. Okay if
> > it passes (modulo changes for the above symtab_get_node() issue)?
>
> After discussion with Honza, consider the patch changed like so:
>
>if (!from_decl
>
Hi,
On Thu, 14 Jun 2012, Michael Matz wrote:
> In any case, this patch is currently in regstrapping on x86-64. Okay if
> it passes (modulo changes for the above symtab_get_node() issue)?
After discussion with Honza, consider the patch changed like so:
if (!from_decl
|| TREE_CODE (fr
Hi,
On Thu, 14 Jun 2012, Jan Hubicka wrote:
> > if (!from_decl
> > ...
> > || (symtab_get_node (from_decl)->symbol.in_other_partition))
> > return true;
> >
> > in can_refer_decl_in_current_unit_p. Honza: I don't understand this
> > particular condition. If we have a
>
> if (!from_decl
> ...
> || (symtab_get_node (from_decl)->symbol.in_other_partition))
> return true;
>
> in can_refer_decl_in_current_unit_p. Honza: I don't understand this
> particular condition. If we have a from_decl (i.e. the decl we're
> concerned about stems
Hi,
[Honza, for you a question below]
On Wed, 13 Jun 2012, Richard Guenther wrote:
> > Was a non-implemented optimization. If the compound literal value
> > isn't used as lvalue and doesn't have its address taken (and generally
> > fits the current predicate) we can as well subst it in place
On Wed, Jun 13, 2012 at 1:46 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 12 Jun 2012, Richard Guenther wrote:
>
>> > Ok, I see the C frontend hands us this as
>> >
>> > return VEC_PERM_EXPR < a , b , <<< Unknown tree: compound_literal_expr
>> > v4si D.1712 = { 0, 4, 1, 5 }; >>> > ;
>> >
>> > an
Hi,
On Tue, 12 Jun 2012, Richard Guenther wrote:
> > Ok, I see the C frontend hands us this as
> >
> > return VEC_PERM_EXPR < a , b , <<< Unknown tree: compound_literal_expr
> > v4si D.1712 = { 0, 4, 1, 5 }; >>> > ;
> >
> > and gimplification in some way fails to gimplify it to { 0, 4, 1, 5
10 matches
Mail list logo
