On Thu, Jul 07, 2005 at 09:31:35AM -0400, Michael Tegtmeyer wrote:
I'm getting crashes for non-trivial code-mostly templates-that
otherwise compiles fine. Am I missing something? Does something else need
to be scheduled before pass_reference_vars?
You would have to show us your patch and
I'm using gcc initially to do some static analysis with the resuts being
sent somewhere else for the time being. I basically just need to gather
the variables with visibility outside of the current function. In addition
I need as little tree transformation prior to this collection as
On Thu, 2005-07-07 at 09:31 -0400, Michael Tegtmeyer wrote:
I'm using gcc initially to do some static analysis with the resuts being
sent somewhere else for the time being. I basically just need to gather
the variables with visibility outside of the current function. In addition
I need as
pass_init_datastructures is still necessary.
That was the problem-thanks.
New question (or still the original rather), is there existing
functionality to obtain the variables used in a function with external
visibility for that function-or in other words-any variable not local to
that
On Thu, Jul 07, 2005 at 12:40:11PM -0400, Michael Tegtmeyer wrote:
In bar, 'i' is not global but is not passed in via arguments either.
referenced_vars contains the 'this' ptr. Is there anything existing that
will obtain 'i' as an external variable w.r.t. bar?
'i' is not a standalone
On Thu, 2005-07-07 at 12:40 -0400, Michael Tegtmeyer wrote:
pass_init_datastructures is still necessary.
That was the problem-thanks.
New question (or still the original rather), is there existing
functionality to obtain the variables used in a function with external
visibility for
struct foo {
int i;
void bar() {i=10;}
};
i is not a regular variable here, it's a member of a structure.
Agreed.
No, but only because it's not really a variable, it's a structure
member, and only ever accessed as such. It thus doesn't appear as a
VAR_DECL (in gcc terms),
On Thu, Jul 07, 2005 at 01:28:18PM -0400, Michael Tegtmeyer wrote:
So the question is, what is the easiest way to obtain the
specific field that was referenced in this case?
You need to traverse the IL and examine the LHS and RHS of
expressions for COMPONENT_REF and INDIRECT_REF expressions.
Hello,
Is there existing functionality somewhere to sweep a function and collect
all externally visible variables at the tree level or do I need to roll my
own? I've looked in tree.h and grepped around as much as I could but I
haven't found anything obvious.
Thanks in advance,
Mike
On Wed, 2005-07-06 at 08:46 -0400, Daniel Berlin wrote:
Most of this can be found in the cgraph nodes. The rest requires
scanning the IL.
Ken Zadeck should have code to do this.
Oh, i assumed you were trying to work at an interprocedural level.
If you only ever care to see a single
On Wed, Jul 06, 2005 at 09:40:08AM -0400, Michael Tegtmeyer wrote:
Thanks-intraprocedural is all I need.
Sorry, bit new to gcc internals (coming from SUIF), is anything missing
from referenced_vars list or is it complete? docs in tree-dfa.c state
that it doesn't look in statement operands.
On Wed, 2005-07-06 at 09:40 -0400, Michael Tegtmeyer wrote:
Thanks-intraprocedural is all I need.
Sorry, bit new to gcc internals (coming from SUIF), is anything missing
from referenced_vars list or is it complete?
It is a complete list of variables *referenced from this function*.
docs
I hope to have my code checked in today.
Look in ipa-reference.c
Kenny
Daniel Berlin wrote:
Most of this can be found in the cgraph nodes. The rest requires
scanning the IL.
Ken Zadeck should have code to do this.
On Wed, 2005-07-06 at 08:32 -0400, Michael Tegtmeyer wrote:
Hello,
Is
13 matches
Mail list logo
