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
