pta: fninfo subvariables involved in offset constraints

Hi richi,

I found a case where the function.clobber varinfo gets included in a points-to
set.  That shouldn't happen right?  It causes trouble for my PTA Steensgaard
project.

Here is a testcase:

---- pr35065-reduced.c ----
enum vlc_module_properties { VLC_MODULE_CB_OPEN };
char ParseNALBlock_p_frag_0;
int vlc_entry__0_9_0f_p_submodule;
void Open();
void vlc_module_set(int *, enum vlc_module_properties, void *);
void vlc_entry__0_9_0f() {
  vlc_module_set(&vlc_entry__0_9_0f_p_submodule, VLC_MODULE_CB_OPEN, Open);
}
void ParseNALBlock();
void Open() { ParseNALBlock(); }
void bs_read_ue();
void ParseNALBlock() {
  if (ParseNALBlock_p_frag_0)
    bs_read_ue();
}
---- ----

I compile it with trunk GCC using these flags:
gcc -c pr35065-reduced.c -fipa-pta -O2 -march=native -fno-inline -fdump-ipa-pta2-details-alias

In the dump you can see this set:
callarg(34) = { ESCAPED Open Open.clobber Open.use Open.result }

I've stepped through PTA in GDB and found that initially,
callarg(34) = { Open }
When we process the constraints callarg(34) = callarg(34) + UNKNOWN,
pta-andersen.cc:solution_set_expand() happilly expands the Open varinfo into
all the subvariables Open.clobber Open.use Open.result.

Is this intentional?

Open.clobber, Open.use, Open.result all have is_full_var = 1, but Open does
not.  What's your gut feeling about setting is_full_var = 1 for fninfos?  It
does help with this testcase but I didn't yet look through the sources to see
if it doesn't break something else.

Filip