Re: [PATCH] Fix PR ipa/65318

[Jan Hubicka <hubicka@ucw.cz>]

> 
> Yes - but I said that having an alias should have the same effect as
> the MEM_REF wrapping we do in LTO (to not barf on stmt verification
> if symbol merging merges an int and a float for example).

Yep, though alias is bit different from LTO - in LTO we replace the decl in place,
while alias still has its oriignal type only its constructor is not necessarily
cooperating. (We sort of do that with -fmerge-constants for CONST_DECL and in constant
pool vairables for ages)
> 
> >
> > Concerning callers handling mismatches, the VIEW_CONVERT_EXPR thing seems valid
> > thing to do for all uses except for fold_const_aggregate_ref_1. So perhaps
> > we can just inline rest of get_symbol_constant_value in there and document that
> > get_symbol_constant_value returns value in correct type.
> >
> > Or am I missing something obvious?
> 
> Yeah, that looks good.  Note that we can as well change all callers
> of get_symbol_constant_value to use fold_const_aggregate_ref, no?
> So reduce the number of APIs.

Yes, that seems like good idea.  As I recall, we used to have get_symbol_constant_value
first and introduced aggregate folding later.

Honza
> 
> Richard.
> 
> >
> > Thanks!
> > Honza
> >>
> >> >+              val = fold_unary (VIEW_CONVERT_EXPR, TREE_TYPE (sym), val);
> >> >+            }
> >> >+          return val;
> >> >+        }
> >> >       else
> >> >         return NULL_TREE;
> >> >     }
> >>