Documentation for 4.0.2
Hi, Any chances that the GCC Internals documentation will be updated any time soon? http://gcc.gnu.org/onlinedocs/gccint/ There have been a lot of changes in GCC and it's hard to figure out the code by reading the old documentation and the new incomplete 4.0.2 draft. Thx. Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
GCC back-ends
Hi, Does GCC front- and middle-end keep the source code line numbers all the way until the RTL is generated? I'd need that for the tool I'm developing. Also, are there any simple source code browsers / static analysis tools that use GCC as the front-/middle-end that I might check out to see how to hook up with GCC? Thx. Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
Re: Documentation for 4.0.2
Hi, > > Any chances that the GCC Internals documentation will be updated any > > time soon? http://gcc.gnu.org/onlinedocs/gccint/ > It looks pretty current to me. Hmm... there're 30 FIXMEs and the section on C trees is missing: Macros-and-Functions.html:57:This section is not here yet. It would be nice if someone could at least update the C trees and GIMPLE sections... > Are you talking about 4.2 or 4.0.2? 4.0.2 Thx. Regards, Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
"Bag of pages" algorithm?
Hi, Could anyone recommend a good reference (paper/book/webpage/...) about the "bag of pages" GC algorithm used in GCC? Also, is there any document about the specifics of GCC implementation (besides GCC Internals document)? Thx. Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
Re: "Bag of pages" algorithm?
Hi Daniel, > > Could anyone recommend a good reference (paper/book/webpage/...) > > about the "bag of pages" GC algorithm used in GCC? > There is none, AFAIK. Argh, how am I supposed to figure out the arcane lore of GCC programmers than? :-) > > Also, is there > > any document about the specifics of GCC implementation (besides > > GCC Internals document)? > Nope. I can just hope that someone actually knows a good reference to recommend or is willing to write "GCC GC for beginners" :-) in a page or two... Thx. Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
Hack in gcc/c-decl.c?
Hi,
Can anyone explain me the following gcc/c-decl.c code (4.0.2, seems to
be unchanged in 4.2)?
...
#define I_SYMBOL_BINDING(node) \
(((struct lang_identifier *)
IDENTIFIER_NODE_CHECK(node))->symbol_binding)
...
static void
warn_if_shadowing (tree new_decl)
{
struct c_binding *b;
...
/* Is anything being shadowed? Invisible decls do not count. */
for (b = I_SYMBOL_BINDING (DECL_NAME (new_decl)); b; b = b->shadowed)
if (b->decl && b->decl != new_decl && !b->invisible)
...
}
...
}
...
Let's assume that new_decl is a VAR_DECL node. Than,
IDENTIFIER_NODE_CHECK(DECL_NAME(new_decl))
= new_decl->decl->name, which is an IDENTIFIER_NODE. How is it
possible to cast it to (struct lang_identifier *) ??
[The worst thing is that it seems to work fine.]
Just to recap:
--
tree.h:
struct tree_identifier GTY(())
{
struct tree_common ommon;
struct ht_identifier id;
};
symtab.h:
struct ht_identifier GTY(())
{
const unsigned char *str;
unsigned int len;
unsigned int hash_value;
};
c-decl.c:
struct c_binding GTY((chain_next ("%h.prev")))
{
tree decl;/* the decl bound */
tree type;/* the type in this scope */
tree id;/* the identifier it's bound to */
struct c_binding *prev;/* the previous decl in this scope */
struct c_binding *shadowed;/* the innermost decl shadowed by this one */
unsigned int depth : 28; /* depth of this scope */
BOOL_BITFIELD invisible : 1; /* normal lookup should ignore this
binding */
BOOL_BITFIELD nested : 1; /* do not set DECL_CONTEXT when popping */
BOOL_BITFIELD inner_comp : 1; /* incomplete array completed in inner
scope */
/* one free bit */
};
c-decl.c:
struct lang_identifier GTY(())
{
struct c_common_identifier common_id;
struct c_binding *symbol_binding; /* vars, funcs, constants, typedefs */
struct c_binding *tag_binding;/* struct/union/enum tags */
struct c_binding *label_binding; /* labels */
};
--
Thx! Regards,
Domagoj
--
___
Play 100s of games for FREE! http://games.mail.com/
Re: Hack in gcc/c-decl.c?
Hi,
Sorry, I didn't see that each identifier *is* a lang_identifier, that's
a weird way to keep bindings. It's not that easy for someone new to GCC
to get around the code. What was the design decision behind that hack
(instead of something like:
struct tree_identifier {
struct tree_common common;
struct c_binding *binds[3];
struct ht_identifier id;
})?
I see that make_node_stat allocates a large enough piece of
memory, but which function actually writes to
I_SYMBOL_X(node)->Y_binding ?
Thx.
Domagoj
- Original Message -
From: "Mike Stump" <[EMAIL PROTECTED]>
To: "Domagoj D" <[EMAIL PROTECTED]>
Subject: Re: Hack in gcc/c-decl.c?
Date: Wed, 28 Dec 2005 23:30:22 -0800
> On Dec 28, 2005, at 8:49 PM, Domagoj D wrote:
> > Can anyone explain me the following gcc/c-decl.c code (4.0.2, seems to
> > be unchanged in 4.2)?
>
> What part was unclear?
>
> > #define I_SYMBOL_BINDING(node) \
> > (((struct lang_identifier *)
> > IDENTIFIER_NODE_CHECK(node))->symbol_binding)
>
> Yes, each identifier is a lang_identifier:
>
>/* sizeof (struct lang_identifier), so make_node () creates
> identifier nodes long enough for the language-specific slots. */
>size_t identifier_size;
>
> > Let's assume that new_decl is a VAR_DECL node. Than,
> > IDENTIFIER_NODE_CHECK(DECL_NAME(new_decl))
> > = new_decl->decl->name, which is an IDENTIFIER_NODE. How is it
> > possible to cast it to (struct lang_identifier *) ??
>
> Because that is the type of the pointer?
>
> > [The worst thing is that it seems to work fine.]
>
> As designed?
--
___
Play 100s of games for FREE! http://games.mail.com/
Re: Hack in gcc/c-decl.c?
Hi, > That can't work, not all tree_identifiers have a c_binding, for > example, java doesn't. I see. > Also, not all identifiers in all languages have an ht_identifier, > again, for example, java doesn't. Hmm... But tree_identifier in tree.h has an ht_identifier struct. So, is gcc/tree.h C-specific? > If you have a patch that makes gcc more understandable, more > conforming to what most people would expect, faster and easier to > maintain and(/or?) smaller please submit it. :-) Ok, will do :-) Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
Re: Hack in gcc/c-decl.c?
> | Another interesting issue would be:
> |
> | struct S {
> | int i;
> | float j;
> | } s;
> |
> | *(float *)((char*)&s + 4);
>
> I was actually referring to this case (or something to that effect) --
> I believe Mark Mitchell was of the opinion that it is undefined
> (though, apologies if I misrepresent exactly the opposite of what he
> said) and another camp thought it should be defined (or the opposite.)
> I don't recall we ever reached an agreement.
> -- Gaby
In the case anybody cares about code verifiability... It's exteremely hard
to automatically prove the correctness of the code that uses pointer
arithmetic and casts as in the example above.
Consider the following example:
enum ftype {T1, T2, T3};
static int calls=0;
union x {
double dparam;
float fparam;
long lparam;
int iparam;
};
struct coefs {
union x ux;
float c1;
float c2;
float c3;
int (*offset_callback)(enum ftype t);
} filter_s;
void init(void) {
filter_s.offset_callback = offset;
int offset(enum ftype t) {
int off = sizeof(union x);
calls++;
switch (t) {
case T1: return off;
case T2: return off + sizeof(float);
case T3: return off + 2*sizeof(float);
}
}
float get_coef(enum ftype t) {
return *(float *)((char *)&filter_s + filter_s.offset_callback(t));
}
enum ftype set_coef(enum ftype t, float val) {
*(float *)((char *)&filter_s + filter_s.offset_callback(t)) = val;
return t;
}
How is the compiler going to figure out that c1,c2 and c3 are actually
used?
Proving more interesting properties like
enum ftype tx;
float fx;
... (assign to tx and fx)
assert(get_coef(set_coef(tx, fx)) == fx);
would be even harder.
Domagoj
--
___
Play 100s of games for FREE! http://games.mail.com/
Re: Hack in gcc/c-decl.c?
Hi Mike,
- Original Message -
> static inline float get_coef(enum ftype t) {
>return *(float *)((char *)&filter_s + filter_s.offset_callback(t));
> }
>
> static inline enum ftype set_coef(enum ftype t, float val) {
>*(float *)((char *)&filter_s + filter_s.offset_callback(t)) = val;
>return t;
> }
>
> void foo();
> void boo() {
>enum ftype tx;
>float fx;
>fx = 1.0;
>tx = T1;
>init();
>if (filter_s.offset_callback != offset)
> if (get_coef(set_coef(tx, fx)) != fx)
>foo();
> }
I guess you meant:
if (filter_s.offset_callback == offset) {
if (get_coef(set_coef(tx, fx)) != fx) foo
}
In your example the call to foo() can be trivially proven to be
unreachable. For the modified example, the model checker has to prove
(assuming get_coef and set_coef have no other side-effects):
*(float *)((char *)&filter_s + offset(tx, fx)) = VAL;
*(float *)((char *)&filter_s + offset(tx, fx)) != VAL;
which is trivially false and can be proven by using uninterpreted
functions (as offset is declared to be pure and const). If there were
several possible offset callbacks and each of them had some
side-effects, the proof would get harder
Happy New Year!
Domagoj
--
___
Play 100s of games for FREE! http://games.mail.com/
