> > 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; > >> > } > >>
