I have the following code:
foo.hh
==
class A
{
};
class foo
{
A a;
public:
void bar(A & aa);
};
foo.cc
==
#include "foo.hh"
void foo::bar(A & aa)
{
a = aa;
}
However the gimple generated via g++-4.5 -c -fdump-tree-gimple foo.cc
is this:
void foo::bar(A&) (struct foo * co
> That *is* the content of the bar method. What exactly do you expect to see
> happening when you assign a class with no members? There's nothing to do!
I was hoping to see the assignment. My example might have been a little
too simple. Here's a slightly more complex example:
foo.hh
clas
On Fri, 2011-02-25 at 19:57 +, Dave Korn wrote:
> On 25/02/2011 19:21, Kyle Girard wrote:
>
> > I was hoping to see the assignment.
>
> > Looking at the gimple output there is no way to see that 'a' was
> > assigned in bar(). So that it can be used
Question, how is the uid for a type calculated? What are the
contributing factors?
Can I count on the uid for a type in a header to be the same across all
compilation units that use that header?
Cheers,
Kyle
> It's simply a counter incremented each time a type node is created (see
> next_type_uid), hence ...
>
Thanks the info.
> > Can I count on the uid for a type in a header to be the same across all
> > compilation units that use that header?
>
> ... no.
>
Is there anyway in gcc to get a uni
> The major issue is to have GCC plugins working on Windows (and, when
> that happens, to adapt existing plugins, including melt.so, to work
> under Windows). I know nothing about the subject, but Levine's book on
> linkers & loaders makes me believe it might not be fun.
>
Just a point of info..
Hello,
I am playing around with a plug-in for gcc but recently ran into the
road block that plug-ins aren't supported on Windows. Are there any
plans to add support for the windows platform in the future? If not,
what are the issues with supporting Windows and how much effort would it
be to add
> The main utility of plugins is that they make developing, testing and
> deploying modifications to gcc easier. I don't think that MS windows users
> will miss too much if they can't dynamically load the plugins, as long
> as their sysadmin can provide them with a linked-in version - the sysadmi
> The attached patch still has some rough edges, like missing main gcc
> ChangeLog, missing documentation, no dso building implemented (should
> eventually work both in-tree to be installed in the plugin dir and
> out-of-tree with a previous built compiler).
>
Well, I definitely owe you some b
Hello,
I currently have a plugin for gcc 4.5 that works great. However, the
need has arisen to have the same plugin run on gcc 3.4.5. Knowing
that the plugin api wasn't added until 4.5 I was wondering if anyone
could tell me how much pain i would be in for if I attempt to backport
the plugin api
I'm trying compile a version of gcc-4.5 on linux x86 for linux x86 which
is relocatable but I'm having difficulty.
Does anyone have an example of how to build such a relocatable gcc?
I've been building binutils, and gcc-4.5 over and over
with many different options. After reading the docs I
I have two files:
foo.h:
extern int x;
extern int y;
foo.c:
#include "foo.h"
int x;
int y;
I have written a gcc plugin that traverses the gcc AST ... However in
the situation where I compile the above file I cannot seem to access the
int x and int y decls. If I place a dummy function in the
12 matches
Mail list logo
