BIT_FIELD_REF on the LHS
So I started to try to fold *(type*)(&vector_type_var) into
BIT_FIELD_REF but I ran into a bug where the SSA messes
itself up.
This works for the right hand side just fine as
BIT_FIELD_REF is easyly valid gimple. When the
BIT_FIELD_REF is on the left hand side, it turns out that we produce:
BIT_FIELD_REF = t_1 still even though t1_2 is killed
during the BIT_FIELD_REF.
I don't see anything in either tree.def or tree-ssa.texi which would
cause the orginal non-gimplified tree to be invalid. So my question
is should we document that BIT_FIELD_REF on the lhs for a SSA_NAME
invalid gimple?
I just looked into the mainline and saw that we actually produce a
checking internal error
while processing this case:
t.c: In function 'f':
t.c:4: error: GIMPLE register modified with BIT_FIELD_REF
BIT_FIELD_REF = t1D.1516_1;
This is not right after into SSA though but right after the alias pass
which seems to me
that the variable should not be marked for a register.
Does anyone have an idea how to get either the aliasing pass not to
mark t for a register or the name and semantics for a tree code which
sets one part of a vector and returns a new vector?
Yes we could produce v = { v[0], v[1], other, v[3] }; but that seems a
bit harder to understand and produce good code from as the expanders
are not so good.
Thanks,
Andrew Pinski
PS http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02150.html added the
ability for having BIT_FIELD_REF on the LHS.
Re: BIT_FIELD_REF on the LHS
On 7/13/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
So I started to try to fold *(type*)(&vector_type_var) into
BIT_FIELD_REF but I ran into a bug where the SSA messes
itself up.
This works for the right hand side just fine as
BIT_FIELD_REF is easyly valid gimple. When the
BIT_FIELD_REF is on the left hand side, it turns out that we produce:
BIT_FIELD_REF = t_1 still even though t1_2 is killed
during the BIT_FIELD_REF.
it's only a partial kill, which you cannot do to ssa names. So you'd need to
go the
t1_2 = { t[0], other, t[1], t[2] }
route to fix this.
Richard.
I don't see anything in either tree.def or tree-ssa.texi which would
cause the orginal non-gimplified tree to be invalid. So my question
is should we document that BIT_FIELD_REF on the lhs for a SSA_NAME
invalid gimple?
I just looked into the mainline and saw that we actually produce a
checking internal error
while processing this case:
t.c: In function 'f':
t.c:4: error: GIMPLE register modified with BIT_FIELD_REF
BIT_FIELD_REF = t1D.1516_1;
This is not right after into SSA though but right after the alias pass
which seems to me
that the variable should not be marked for a register.
Does anyone have an idea how to get either the aliasing pass not to
mark t for a register or the name and semantics for a tree code which
sets one part of a vector and returns a new vector?
Yes we could produce v = { v[0], v[1], other, v[3] }; but that seems a
bit harder to understand and produce good code from as the expanders
are not so good.
Thanks,
Andrew Pinski
PS http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02150.html added the
ability for having BIT_FIELD_REF on the LHS.
Re: BIT_FIELD_REF on the LHS
On 7/13/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 7/13/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> So I started to try to fold *(type*)(&vector_type_var) into
> BIT_FIELD_REF but I ran into a bug where the SSA messes
> itself up.
> This works for the right hand side just fine as
> BIT_FIELD_REF is easyly valid gimple. When the
> BIT_FIELD_REF is on the left hand side, it turns out that we produce:
> BIT_FIELD_REF = t_1 still even though t1_2 is killed
> during the BIT_FIELD_REF.
it's only a partial kill, which you cannot do to ssa names. So you'd need to
go the
t1_2 = { t[0], other, t[1], t[2] }
route to fix this.
This looks _so_ much like the SUBREG issues with RTL SSA :-)
Gr.
Steven
Re: BIT_FIELD_REF on the LHS
PS http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02150.html added the ability for having BIT_FIELD_REF on the LHS. Yes, but IIRC that was only for addressable things, not for registers. As Steven said, handling it would be a mess like it was for RTL SSA. So, you Do Not Want this for registers. Paolo
Re: Wiki down for a few days
Hi Daniel, The Wcoercion porject page is currently up at http://gcc.gnu.org/wiki/Wcoercion and it is vandalised. Yet, I cannot revert or change it. Could you do something about this please? Taking it down for a few days would be better than current situation. Cheers, Manuel. On 12/07/06, Daniel Berlin <[EMAIL PROTECTED]> wrote: I'm taking the wiki down for a few days because 1. It's getting attacked again, and the current software doesn't make fixing this easy. 2. I'm currently not at home, and have a lot of meetings, so i probably won't finish converting it until i get back home. :) Sorry about this. --Dan
Re: request for new a syntactic design for C/C++.
Ian Lance Taylor wrote:
"Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> writes:
Current syntax C/C++:
load_ptr = typeof(load_ptr)(((char *)init_ptr) - \
offsetof(typeof(init_ptr), field);
The offered syntax:
&load_ptr->field = init_ptr;
Interesting idea, but C/C++ programmers expect that an assignment sets
the entire expression on the left of the '='. So I don't think this
is a good syntax.
&load_ptr->field = init_ptr;
For given line only `load_ptr' variable will be changed. This changes based
on `init_ptr' variable and on the name of the field. Field name parameter is
static. May be it's not so dramatic ? Let me show you as example attached
file: "example1.c".
There is one another example. Many of interpretation languages have a
general
header in the element structure (and not only languages). Type definition is
very frequently uses operation just for transit pointer to the object over
C-API:
struct head_of_object {
int type;
...
};
struct one_type {
struct head_of_object head;
...
};
Currently syntactic design definition of function and a few lines in
the body is look like:
struct head_of_object *
function(struct head_of_object *ob_head) {
...
struct one_type *ob = (struct one_type *)ob_head;
...
return &ob->ob_head;
...
}
This is some asymmetrically. Type definition in this case is not required.
With given purposes it will be become to look like:
struct head_of_object *
function(struct one_type &ob->head) {
...
return &ob->ob_head;
...
}
For passed argument it is require pointer to a type of field `head'
(struct head_of_object *). In body of function pointer `ob' have
type "struct one_type". Magnitude this syntactic construction
is the same as in previous examples.
In fact you can already write what you want with a macro, one quite
similar to offsetof, so I don't think we need any new syntactic sugar
here.
It's really only syntactic changes. With this extension code become
more clear. Of course, it's not one way to do it. I just give one
clause.
And one more example:
type_to_find *one_ptr;
struct type2 {
type1field1;
type2field2;
type_to_find field3;
} *two_ptr = init_something;
#if 1
// case 1
one_ptr = &two_ptr->field3; // This is okay. Is it a really
syntactic sugar ?
#else
// case 2
one_ptr = typeof(one_ptr)(((char *)two_ptr) + \
sizeof(two_ptr->field1) + \
sizeof(two_ptr->field2)); // And this is okay.
// But nobody use it
// because it is
// heavily and
unsafe.
#endif
C++:
struct some_struct &link = other;
This already means something in C++: it means to create a reference.
Yes. I just want to point for similar syntax.
typedef union __genlink {
struct {
union __genlink *qcl_prev;
union __genlink *qcl_next;
} qcl; /* Queue/Cycle/List */
void*point[2];
union __genlink *link[2];
} genlink;
struct timeout_and_refresh_list {
int type;
genlink node_timeout;
genlink node_refresh;
time_t tm_start;
time_t tm_last;
char *str;
};
genlink timeout_root;
genlink refresh_root;
void
qcl_init(genlink *root) {
root->qcl.qcl_next = root;
root->qcl.qcl_prev = root;
}
void
qcl_insert_before(genlink *root, genlink *p) {
genlink *prev;
p->qcl.qcl_next = root;
p->qcl.qcl_prev = (prev = root->qcl.qcl_prev);
root->qcl.qcl_prev = prev->qcl.qcl_next = p;
}
void
example_init() {
qcl_init(&timeout_root);
qcl_init(&refresh_root);
}
bool
example_add(struct timeout_and_refresh_list *list, char *str, time_t tm) {
struct timeout_and_refresh_list *elem;
genlink *p;
for (p = &list->refresh_root;;) {
/*
* Walk on the `refresh' list.
*/
if ((p = p->qcl.qcl_next) == &list->refresh_root) {
/*
* Element is not found. Make a new one.
*/
if ((elem = malloc(sizeof(*elem))) == NULL)
goto failed;
elem->tm_start = elem->tm_last = tm;
elem->str = strdup(str);
qcl_insert_before(&refresh_root, elem);
qcl_insert_before(&timeout_root, elem);
break;
}
#if 1 // Current syntax C/C++
elem = (struct timeout_and_refresh_list *)(
((char *)p) - \
offsetof(struct timeout_and_refresh_list,
node_r
Re: gcc visibility used by moz
Jason Merrill <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | >> Joe Buck wrote: | > Now, this being a conscious decision for ODR violation, it would | > probably need to be documented because then we may have | >typeinfo1 != typeinfo2 | > and yet | > !typeinfo1.before(typeinfo2) && !typeinfo2.before(typeinfo1) | > There are probably other inconsistencies to audit. | > | We can have two distinct | > | classes named S, and no one can tell. Each bit of code will see one | > | definition of S. | | I think that Joe's point is that IF you have two classes named S, then | they're hidden away in separate shared libraries and you can't compare | them, because no piece of code knows about both of them. I'm not clear about "you can't compare them". Surely, I can take the address of typeid(S) and pass it around to a function in another translation unit. I can do typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2 comes from two such different translation units. How the current visibility framework prevent that from happening? [storing the address of typeid(S) is usually found on variations on the Factory design pattern.] | Any class | that is part of the public interface of a shared library is part of | the public interface, and therefore must be unique through the program. Yes. One of the interesting parts is what happens when those classes have external linkage but hidden visibility. | In any case, this ODR business seems rather tangential to the | discussion of visibility semantics. The primary purpose of the | visibility work is limiting the number of symbols exported from a | particular shared library in order to cut down on load time. Can we | please focus on the semantics we want for that instead of trying to | solve a theoretical problem that has been around as long as people | have tried to use shared libraries with C++? I think we can assume that people are focusing on the semantics. However, we should not handwave serious ODR issues. We have gotten lots of PRS from real codes against the visibility stuff due to reasons I would trace to "oh, that issue should not matter in practice". The complexity of the issue should push us to hide under the cover of theoretical problem :-) Because of the semantics of type_info objects, it is not clear to me yet how the ODR issue is orthogonal to the visibility semantics. An easy way out may to be to declare the combination external linkage + hidden visibility for the "same" class in differrent translation units as an ODR violation, i.e. the program has an undefined behaviour. That puts a restriction, that might be considered "severe" or not. -- Gaby
Re: BIT_FIELD_REF on the LHS
Andrew Pinski wrote on 07/13/06 03:27: > I don't see anything in either tree.def or tree-ssa.texi which would > cause the orginal non-gimplified tree to be invalid. So my question > is should we document that BIT_FIELD_REF on the lhs for a SSA_NAME > invalid gimple? > SSA_NAMEs should not be valid operands for BIT_FIELD_REF, neither on the LHS nor the RHS. An SSA name is by definition a complete, atomic reference. Got a test case where we produce BIT_FIELD_REF in either side of the assignment?
Re: BIT_FIELD_REF on the LHS
On Jul 13, 2006, at 9:32 PM, Diego Novillo wrote:
Got a test case where we produce BIT_FIELD_REF in
either
side of the assignment?
Well a simple one like for the RHS on PPC-linux-gnu with -maltivec
(and -O1):
#define vector __attribute__((vector_size(16) ))
vector float f(vector float t, vector t1)
{
return t/t1;
}
-- Pinski
Re: BIT_FIELD_REF on the LHS
Andrew Pinski wrote on 07/13/06 08:37:
> #define vector __attribute__((vector_size(16) ))
>
> vector float f(vector float t, vector t1)
> {
> return t/t1;
> }
>
> -- Pinski
>
That definitely seems wrong. We shouldn't be considering vector types
to be GIMPLE register types if we are going to be chunking them out with
BIT_FIELD_REF. The verifier ought to check that.
Allowing SSA names to be accessed in a non-atomic fashion is a recipe
for bad codegen.
Re: BIT_FIELD_REF on the LHS
On Jul 13, 2006, at 10:06 PM, Diego Novillo wrote: That definitely seems wrong. We shouldn't be considering vector types to be GIMPLE register types if we are going to be chunking them out with BIT_FIELD_REF. The verifier ought to check that. I am thinking about cleaning this up by using DECL_COMPLEX_GIMPLE_REG_P for vectors also (maybe renaming it), do you think that is a good idea? Thanks, Andrew Pinski
Bug in the specs or bug in the code?
Hi
Bug in the specs or bug in the code?
I do not know, but one of this is wrong:
In the Linux Standard specs in
http://www.freestandards.org/spec/booksets/LSB-Core-generic/LSB-Core-generic/ehframechpt.html
it is written in the specification of the FDE (Frame Description Entry)
the following:
CIE Pointer
A 4 byte unsigned value that when subtracted from the offset of the
current FDE
yields the offset of the start of the associated CIE. This value
shall never be 0.
So, the offset is from the beginning of the current FDE, the specs say
BUT
What does the code say?
In the file unwind-dw2-fde.h we find:
/* Locate the CIE for a given FDE. */
static inline const struct dwarf_cie *
get_cie (const struct dwarf_fde *f)
{
return (void *)&f->CIE_delta - f->CIE_delta;
}
Note that the first term is &f->CIE_delta and NOT &f as specified by the
standard.
This fact took me two days of work for finding it out. Either a bug in
the code
a bug in the specs. The difference is 4 bytes since CIE_delta comes
after the length
field.
Please fix the specs, since if you fix the code everything will go
crashing as my
program did...
jacob
How to insert dynamic code? (continued)
Hi Context: I am writing a JIT and need to register the frame information about the generated program within the context of a larger C++ program compiled with g++. Stack layout is like this: catch established by C++ JITTED code generated dynamically JITTED code JITTED code calls a C++ routine C++ routine calls other C++ routines C++ routine makes a THROW The throw must go past the JITTED code to the established C++ catch. Problem. The stack unwinder stops with END_OF_STACK at the Jitted code. Why? Following the code with the debugger I see that the unwider looks for the next frame using the structures established by the dynamic loader, specifically in the function "__dl_iterate_phdr" in the file "dl-iteratephdr.c" in the glibc. So, this means: 1) I am cooked and what I want to do is impossible. This means I will probably get cooked at work for proposing something stupid like this :-) 2) There is an API or a way of adding at run time a routine to the lists of loaded objects in the same way as the dynamic loader does. PLEEZE do not answer with: "Just look at the code of the dynamic loader!" because I have several megabytes of code to understand already! I am so near the end that it would be a shame to stop now. My byte codes for the DWARF interpreter LOAD into the interpreter successfully, and they are executed OK, what has costed me several weeks of efforts, wading through MBs of code and missing/wrong specs. I just would like to know a way of registering (and deregistering obviously) code that starts at address X and is Y bytes long. JUst that. Thanks in advance guys jacob
Re: Bug in the specs or bug in the code?
On Thu, Jul 13, 2006 at 04:46:19PM +0200, jacob navia wrote: > In the Linux Standard specs in > http://www.freestandards.org/spec/booksets/LSB-Core-generic/LSB-Core-generic/ehframechpt.html > it is written in the specification of the FDE (Frame Description Entry) > the following: I suggest you report this problem to the LSB, since they wrote that documentation. The documentation is incorrect. -- Daniel Jacobowitz CodeSourcery
Re: How to insert dynamic code? (continued)
jacob navia writes: > Hi > > Context: > > I am writing a JIT and need to register the frame information about > the generated program within the context of a larger C++ program > compiled with g++. Stack layout is like this: > > catch established by C++ > JITTED code generated dynamically > JITTED code > JITTED code calls a C++ routine > C++ routine calls other C++ routines > C++ routine makes a THROW > > The throw must go past the JITTED code to the established C++ catch. > > Problem. > > The stack unwinder stops with END_OF_STACK at the Jitted code. Why? > Following the code with the debugger I see that the unwider looks > for the next frame using the structures established by the dynamic loader, > specifically in the function "__dl_iterate_phdr" in the file > "dl-iteratephdr.c" in the glibc. > > So, this means: > > 1) I am cooked and what I want to do is impossible. This means I will > probably >get cooked at work for proposing something stupid like this :-) > > 2) There is an API or a way of adding at run time a routine to the lists >of loaded objects in the same way as the dynamic loader does. > > PLEEZE do not answer with: > > "Just look at the code of the dynamic loader!" > > because I have several megabytes of code to understand already! > > I am so near the end that it would be a shame to stop now. My byte > codes for the DWARF interpreter LOAD into the interpreter > successfully, and they are executed OK, what has costed me several > weeks of efforts, wading through MBs of code and missing/wrong > specs. > > I just would like to know a way of registering (and deregistering > obviously) code that starts at address X and is Y bytes long. JUst > that. The way you do not reply to mails replying to your questions doesn't encourage people to help you. Please try harder to answer. I suspect that the gcc unwinder is relying on __dl_iterate_phdr to scan the loaded libraries and isn't using the region that you have registered. But this is odd, becasue when I look at _Unwind_Find_FDE in unwind-dw2-fde-glibc.c, I see: ret = _Unwind_Find_registered_FDE (pc, bases); ... if (dl_iterate_phdr (_Unwind_IteratePhdrCallback, &data) < 0) return NULL; So, it looks to me as though we do call _Unwind_Find_registered_FDE first. If you have registered your EH data, it should be found. So, what happens when _Unwind_Find_registered_FDE is called? Does it find the EH data you have registered? Andrew.
Re: How to insert dynamic code? (continued)
Andrew Haley wrote: The way you do not reply to mails replying to your questions doesn't encourage people to help you. Please try harder to answer. I did answer last time but directly to the poster that replied, and forgot to CC the list. Excuse me for that. I suspect that the gcc unwinder is relying on __dl_iterate_phdr to scan the loaded libraries and isn't using the region that you have registered. But this is odd, becasue when I look at _Unwind_Find_FDE in unwind-dw2-fde-glibc.c, I see: ret = _Unwind_Find_registered_FDE (pc, bases); ... if (dl_iterate_phdr (_Unwind_IteratePhdrCallback, &data) < 0) return NULL; So, it looks to me as though we do call _Unwind_Find_registered_FDE first. If you have registered your EH data, it should be found. OK, so I have to look there then. Actually this is good news because figuring out how to mess with the dynamic loader data is not something for the faint of heart :-) So, what happens when _Unwind_Find_registered_FDE is called? Does it find the EH data you have registered? Yes but then it stops there instead of going upwards and finding the catch! It is as my insertion left the list of registered routines in a bad state. I will look again at this part (the registering part) and will try to find out what is going on. Thanks for yourt answer. If you are right this is a very GOOD news! jacob
Re: Different invariants about the contents of static links
http://earth.google.com/download-earth.html On 7/13/06, DebianTux23 <[EMAIL PROTECTED]> wrote: http://earth.google.com/download-earth.html On 07 Jul 2006 10:11:01 -0700, Ian Lance Taylor < [EMAIL PROTECTED]> wrote: > "Rodney M. Bates" < [EMAIL PROTECTED]> writes: > > > The following example C code and disassembly is compiled by gcc 3.4.3, > > for i686. It uses two different invariants for what the value of > > a static link is. Everywhere inside P, static link values are consistently > > the same as base pointer (%ebp) register values for the same activation > > record. A static link value is generated at 4c: in P, and used at > > 22: in PInner2 and c: in PInner1. > > > > Everywhere inside similar function Q, static link values consistently point > > 8 bytes higher than where the base register points. A value is generated at > > d9: in Q and used at 7a: in Qinner2 and 64: in QInner1. > > > > From the examples I have looked at, it looks like it is correct translation, > > and, expect for seeming strangeness, is not a problem for execution. > > > > However, I am working on an extended gdb-derived debugger that works, > > in part, with code produced by a gcc-derived code generator for > > Modula-3. So far, I can't find out, in the debugger, which invariant > > is in use. I have the debugger correctly both generating and using > > static links when evaluating user-typed expressions, using the first > > invariant. I could easily change it to use the second invariant, but > > obviously, that would fix some cases and break others. > > > > Is there a compelling reason for this difference? If not, I would like to > > make it all use invariant one. Also, does anybody know where in gcc this > > difference is happening? I poked around in the source for a couple of hours, > > but didn't see anything obvious. > > The static link pointer points to a part of the stack frame which > includes the information required for the nested functions. The > amount of information required changes depending on the code. > Therefore, the static link pointer will not be a constant offset from > the frame pointer. I don't believe that it is possible to change this > while still handling calls between doubly nested functions, but maybe > I just haven't thought about it hard enough. > > > BTW, this is using stabs. I know that is not very complete, but it would be > > a lot more work than I want to do to change it. > > Stabs doesn't represent the static link pointer at all, so that is > your problem. You should switch to DWARF. If that is impossible as > you suggest, then I think your most profitable approach would be to > enhance stabs somehow. > > Ian >
Re: Bug in the specs or bug in the code?
Daniel Jacobowitz wrote: On Thu, Jul 13, 2006 at 04:46:19PM +0200, jacob navia wrote: In the Linux Standard specs in http://www.freestandards.org/spec/booksets/LSB-Core-generic/LSB-Core-generic/ehframechpt.html it is written in the specification of the FDE (Frame Description Entry) the following: I suggest you report this problem to the LSB, since they wrote that documentation. The documentation is incorrect. Mmmm "report this problem to the LSB". Maybe you have someone there I could reach? An email address? There is no "feedback" or "bugs" button in their page. Thanks
Re: How to insert dynamic code? (continued)
On Thu, Jul 13, 2006 at 05:06:25PM +0200, jacob navia wrote: > >So, what happens when _Unwind_Find_registered_FDE is called? Does it > >find the EH data you have registered? > > > > > > > Yes but then it stops there instead of going upwards and finding the catch! > It is as my insertion left the list of registered routines in a bad state. > > I will look again at this part (the registering part) and will try to > find out what > is going on. It sounds to me more like it used your data, and then was left pointing somewhere garbage, not to the next frame. That is, it sounds like there's something wrong with your generated unwind tables. That's the usual cause for unexpected end of stack. -- Daniel Jacobowitz CodeSourcery
Re: Bug in the specs or bug in the code?
On Thu, Jul 13, 2006 at 05:10:19PM +0200, jacob navia wrote: > Mmmm "report this problem to the LSB". > > Maybe you have someone there I could reach? > An email address? > > There is no "feedback" or "bugs" button in their page. Try http://www.freestandards.org/en/LSB -> lsb-discuss mailing list? -- Daniel Jacobowitz CodeSourcery
Re: Wiki down for a few days
Manuel López-Ibáñez wrote: > Hi Daniel, > > The Wcoercion porject page is currently up at > http://gcc.gnu.org/wiki/Wcoercion and it is vandalised. Yet, I cannot > revert or change it. Could you do something about this please? Taking > it down for a few days would be better than current situation. Fixed, sorry about that. > > Cheers, > > Manuel. > > On 12/07/06, Daniel Berlin <[EMAIL PROTECTED]> wrote: >> I'm taking the wiki down for a few days because >> 1. It's getting attacked again, and the current software doesn't make >> fixing this easy. >> 2. I'm currently not at home, and have a lot of meetings, so i probably >> won't finish converting it until i get back home. :) >> >> Sorry about this. >> >> --Dan >> >
Re: request for new a syntactic design for C/C++.
Mike Stump wrote: On Jul 9, 2006, at 10:52 PM, Vladimir 'Yu' Stepanov wrote: I would like to offer one expansion for C/C++. Did you just reinvent downcasting in C++? If so, C++ already has that feature!? As for C, C, I'd claim C already has that feature[1], you merely have to put in a #define into your library to make it look pretty. In C, since this is a library issue, the compiler would be the wrong place to put the feature. Since it can be done with a macro, there is little need to change the grammar of the language. I cannot to understand. I think what this feature is misses on C and C++. Macros is not good choice. Just macros is exclusive method for now. Given expansion have more clear syntax and mostly it is shortly. Macros is inconstant and cannot do a type verification. > 1 - Contentious, should be decided by C committee IMHO. Of course. But it is may be not go so far. And I don't know about any email of theirs (joke). It is really not needed so often in existing style of programing. But this feature may be very usable for some other style of programing. Thanks.
Re: How to insert dynamic code? (continued)
Daniel Jacobowitz wrote:
On Thu, Jul 13, 2006 at 05:06:25PM +0200, jacob navia wrote:
So, what happens when _Unwind_Find_registered_FDE is called? Does it
find the EH data you have registered?
Yes but then it stops there instead of going upwards and finding the catch!
It is as my insertion left the list of registered routines in a bad state.
I will look again at this part (the registering part) and will try to
find out what
is going on.
It sounds to me more like it used your data, and then was left pointing
somewhere garbage, not to the next frame. That is, it sounds like
there's something wrong with your generated unwind tables. That's the
usual cause for unexpected end of stack.
Yeah...
My fault obviously, who else?
Problem is, there are so mny undocumented stuff that I do not see how I
could
avoid making a mistake here.
1) I generate exactly the same code now as gcc:
Prolog:
push %ebp
movq %rsp,%rbp
subqxxx,%rsp
and I do not touch the stack any more. Nothing is pushed, in the "xxx"
is already the stack
space for argument pushing reserved, just as gcc does. This took me 3
weeks to do.
Now, I write my stuff as follows:
1) CIE
2) FDE for function 1
. 1 fde for each function
3) Empty FDE to zero terminate the stuff.
4) Table of pointers to the CIE, then to the FDE
p = result.FunctionTable; // Starting place, where CIE, then
FDEs are written
p = WriteCIE(p); // Write first the CIE
pFI = DefinedFunctions;
nbOfFunctions=0;
pFdeTable[nbOfFunctions++] = result.FunctionTable;
while (pFI) { // For each function, write the FDE
fde_start = p;
p = Write32(0,p); // reserve place for length field (4
bytes)
p = Write32(p - result.FunctionTable,p); //Write offset
to CIE
symbolP = pFI->FunctionInfo.AssemblerSymbol;
adr = (long long)symbolP->SymbolValue;
adr += (unsigned long long)code_start; // code_start is
the pointer to the Jitted code
p = Write64(adr,p);
p = Write64(pFI->FunctionSize,p); // Write the length in
bytes of the function
*p++ = 0x41;/// Write the opcodes
*p++ = 0x0e; // This opcodes are the same as gcc writes
*p++ = 0x10;
*p++ = 0x86;
*p++ = 0x02;
*p++ = 0x43;
*p++ = 0x0d;
*p++ = 0x06;
p = align8(p);
Write32((p - fde_start)-4,fde_start);// Fix the length
of the FDE
pFdeTable[nbOfFunctions] = fde_start; // Save pointer to
it in table
nbOfFunctions++;
pFI = pFI->Next; // loop
}
The WriteCIE function is this:
static unsigned char *WriteCIE(unsigned char *start)
{
start = Write32(0x14,start);
start = Write32(0,start);
*start++ = 1; // version 1
*start++ = 0; // no augmentation
*start++ = 1;
*start++ = 0x78;
*start++ = 0x10;
*start++ = 0xc;
*start++ = 7;
*start++ = 8;
*start++ = 0x90;
*start++ = 1;
*start++ = 0;
*start++ = 0;
start = Write32(0,start);
return start;
}
I hope this is OK...
jacob
Re: How to insert dynamic code? (continued)
jacob navia writes: > Andrew Haley wrote: > > >I suspect that the gcc unwinder is relying on __dl_iterate_phdr to > >scan the loaded libraries and isn't using the region that you have > >registered. > > > >But this is odd, becasue when I look at _Unwind_Find_FDE in > >unwind-dw2-fde-glibc.c, I see: > > > > ret = _Unwind_Find_registered_FDE (pc, bases); > > > > ... > > > > > > if (dl_iterate_phdr (_Unwind_IteratePhdrCallback, &data) < 0) > >return NULL; > > > >So, it looks to me as though we do call _Unwind_Find_registered_FDE > >first. If you have registered your EH data, it should be found. > > > > > > > OK, so I have to look there then. Actually this is good news because > figuring out how to mess with the dynamic loader data is not something > for the faint of heart :-) True. > >So, what happens when _Unwind_Find_registered_FDE is called? Does it > >find the EH data you have registered? > > > > > > > Yes but then it stops there instead of going upwards and finding the catch! > It is as my insertion left the list of registered routines in a bad state. OK, so the problem is in decoding the unwinder data, and you're just going to have to single-step through the part where it decodes the data you've generated. Andrew.
Re: BIT_FIELD_REF on the LHS
Diego Novillo wrote:
Andrew Pinski wrote on 07/13/06 08:37:
#define vector __attribute__((vector_size(16) ))
vector float f(vector float t, vector t1)
{
return t/t1;
}
-- Pinski
That definitely seems wrong. We shouldn't be considering vector types
to be GIMPLE register types if we are going to be chunking them out with
BIT_FIELD_REF.
Andrew's example currently chunks out t, using BIT_FIELD_REF on the RHS.
The returned value is then built with a CONSTRUCTOR.
Allowing SSA names to be accessed in a non-atomic fashion is a recipe
for bad codegen.
Only writing them, IIUC. Reading should be ok.
This patch is sufficient for BIT_FIELD_REF on the LHS to be marked
correctly as addressable:
Index: ../../gcc/tree-ssa-operands.c
===
--- ../../gcc/tree-ssa-operands.c (revision 115364)
+++ ../../gcc/tree-ssa-operands.c (working copy)
@@ -2006,6 +2006,8 @@ get_expr_operands (tree stmt, tree *expr
case BIT_FIELD_REF:
/* Stores using BIT_FIELD_REF are always preserving definitions. */
+ if (flags & opf_is_def)
+ add_to_addressable_set (TREE_OPERAND (expr, 0),
&s_ann->addresses_taken);
flags &= ~opf_kill_def;
/* Fallthru */
GCC will then happily use VOPS for that variable:
vector float f(vector float t, float t1)
{
*(float*)&t = t1;
return t;
}
has this .uncprop dump:
f (t, t1)
{
vector float D.1522;
# t_3 = V_MAY_DEF ;
BIT_FIELD_REF = t1_1;
# VUSE ;
D.1522_4 = t;
return D.1522_4;
}
But if you say this is dangerous, yes, I agree that the best thing to do
is to treat VECTOR_TYPEs like COMPLEX_TYPEs and use
DECL_COMPLEX_GIMPLE_REG_P. Does COMPOSITE_TYPE_P, and
DECL_COMPOSITE_GIMPLE_REG_P sound good as names?
Paolo
Re: BIT_FIELD_REF on the LHS
Paolo Bonzini wrote on 07/13/06 11:55: > But if you say this is dangerous, yes, I agree that the best thing to do > is to treat VECTOR_TYPEs like COMPLEX_TYPEs and use > DECL_COMPLEX_GIMPLE_REG_P. Does COMPOSITE_TYPE_P, and > DECL_COMPOSITE_GIMPLE_REG_P sound good as names? > Yes, I think that should be fine. Some care should be taken here as we sometimes ask for TREE_CODE == COMPLEX_TYPE directly.
gcc 4.x can not optimize access for array well
I found gcc 4.1.1 (and 4.2) can not optimize this simple code well.
void foo(int *a)
{
int i;
for (i = 0; i < 100; i++)
a[0] += a[1];
}
If I compile this code with -O2, instructions to load from a[1] and
store to a[0] are both inside a loop.
Is this a know issue? PR20463 or PR21676 or any other?
Followings are outputs from some gcc versions on mips and i386.
gcc 4.1.1 on mips: (no good)
foo:
.setnoreorder
.setnomacro
lw $3,0($4)
addiu $6,$4,4
move$5,$0
li $7,100 # 0x64
$L2:
lw $2,0($6)
addiu $5,$5,1
addu$2,$3,$2
move$3,$2
bne $5,$7,$L2
sw $2,0($4)
j $31
nop
gcc 4.2 on mips: (no good)
foo:
.setnoreorder
.setnomacro
lw $3,0($4)
lw $2,4($4)
addiu $6,$4,4
addu$3,$3,$2
sw $3,0($4)
li $5,1# 0x1
$L2:
lw $2,0($6)
addiu $5,$5,1
addu$3,$3,$2
li $2,100 # 0x64
bne $5,$2,$L2
sw $3,0($4)
j $31
nop
gcc 4.2 on i386:
foo:
pushl %ebp
movl$1, %edx
movl%esp, %ebp
pushl %ebx
movl8(%ebp), %ebx
movl4(%ebx), %eax
leal4(%ebx), %ecx
addl(%ebx), %eax
movl%eax, (%ebx)
.p2align 4,,7
.L2:
addl(%ecx), %eax
addl$1, %edx
cmpl$100, %edx
movl%eax, (%ebx)
jne .L2
popl%ebx
popl%ebp
ret
gcc 3.4.6 on mips: (good)
foo:
.setnoreorder
.setnomacro
lw $5,0($4)
lw $6,4($4)
li $2,99 # 0x63
$L5:
addu$3,$5,$6
addiu $2,$2,-1
bgez$2,$L5
move$5,$3
j $31
sw $3,0($4)
gcc 3.4.4 on i386: (good)
foo:
pushl %ebp
movl%esp, %ebp
pushl %esi
pushl %ebx
movl8(%ebp), %esi
movl(%esi), %ecx
movl4(%esi), %ebx
movl$99, %eax
.p2align 4,,15
.L5:
leal(%ecx,%ebx), %edx
decl%eax
movl%edx, %ecx
jns .L5
movl%edx, (%esi)
popl%ebx
popl%esi
popl%ebp
ret
---
Atsushi Nemoto
Re: gcc visibility used by moz
I wrote [for two classes S with visibility == hidden ] > | > | We can have two distinct > | > | classes named S, and no one can tell. Each bit of code will see one > | > | definition of S. Jason Merrill <[EMAIL PROTECTED]> writes: > | I think that Joe's point is that IF you have two classes named S, then > | they're hidden away in separate shared libraries and you can't compare > | them, because no piece of code knows about both of them. Yes. It is sometimes necessary with very large software systems to use tricks like this because someone was sloppy about naming (particularly in older code that comes from times before namespaces were universally available, and many of us do have to deal with 7-10 year old code on occasion). On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote: > I'm not clear about "you can't compare them". > > Surely, I can take the address of typeid(S) and pass it around to > a function in another translation unit. I can do > typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2 comes > from two such different translation units. > > How the current visibility framework prevent that from happening? By a note in the documentation telling the user "don't do that". I think it's safest just to say that if people want to use hidden visibility to violate the ODR, and they succeed in getting a pointer to class S from libfoo.so, and a pointer to the distinct class S from libbar.so, into the same hunk of code and then try to compare the typeinfo objects, that we simply don't define what happens. I think it would be a mistake to try to define the semantics in this case.
Re: A correction: Different invariants about the contents of static links]
"Rodney M. Bates" <[EMAIL PROTECTED]> writes:
> When executing in foo, the frame pointer will point to a fixed spot in the
> activation record of foo. On i386, the FP is %ebx and it points to the
> dynamic link field. From there, loc is at displacement -4. Code in the
> body of foo will reference x at -4(FP).
>
> When we get into any instance of s1, s1's AR will contain a static link that
> points to the AR of foo, which is what you said. The question is where
> in foo's AR does the SL point to. It would make sense for it to be the same
> as where the frame pointer points when executing in foo, i.e., the static
> link would point to the dynamic link field of foo's AR. Then x could be
> accessed from within sl by loading the SL into some register, say REG, and
> referring to -4(REG). loc is at the same displacement relative to the static
> link in s1 as is used in foo relative to the FP.
Thanks for the explanation. I think I may now understand what you are
getting at.
Consider this slight adjustment to your example:
extern void bar (int *, int *);
int
foo (int x, int y)
{
int a;
int loc;
int b;
int
s1 ()
{
if (--y == 0)
return 0;
return loc + s1 ();
}
loc = x;
bar (&a, &b);
bar (&a, &b);
return s1 ();
}
When I compile this, the static chain is 24 bytes off from the frame
pointer. That example was just to show an aspect of how gcc
implements the activation record. gcc builds a struct holding all the
information which needs to be referenced. Then it passes the address
of that struct as the static chain.
If you pass a variable size object (e.g., int a[i]) then gcc will
store a pointer to that object in the activation record. gcc will
also store a pointer if you try to pass down a struct which is a
parameter in the calling function. These are examples where it isn't
obvious that we want the static chain pointer to be the same as the
frame pointer.
That said, I think I now agree that since the activation record always
has a constant size, we could make the static chain pointer always be
the same as the frame pointer. The users would apply a constant
offset to their static chain pointer to get to the activation record.
Issues would arise on processors with limited offset space in
addresses, but those issues are solvable.
> This all executes correctly, even if it's a bit strange. But it has to take
> extra trouble for the code generator to keep track of two different reference
> addresses for the same AR and adjust SL offsets to be different from FP
> offsets for the same AR. I can't see any benefit. It doesn't change the
> set of fields a SL can access in the AR it points to a bit. Only the
> displacements needed change.
Actually, it is not extra trouble for the code generator, it is less
trouble. The code generator simply builds an internal struct to serve
as the activation record, puts the struct on the stack, and makes the
static chain always be a pointer to that struct. The code generator
moves simple values into the struct, and stores pointers for complex
values. Then all references through the static chain are easy to
implement.
Making the static chain be the same as the frame pointer requires a
bit of extra work because the frame pointer can be eliminated to the
stack pointer (via the -fomit-frame-pointer option, which is the
default for some processors when optimizing). The static chain
pointer would have to be eliminated just as the frame pointer is.
> And it wouldn't matter to me, except it's making it a lot more difficult
> to give gdb the ability to execute gdb-user-typed calls on nested functions
> and pass nested functions as parameters (where gdb has to generate static
> link values) and print nonlocal variables (where gdb has to know how to
> interpret the contents of a SL).
To make that work is going to take more than making the static chain
pointer and the frame pointer equivalent. You are going to have to
know how to build the activation record, which as we have seen can
contain pointers to variables which live in the frame.
So I think you are on the wrong path here. Instead of trying to
equate the static chain pointer and the frame pointer, I think what
you need to do is find some way for the debugging information to
describe the activation record, and to describe where it lives on the
stack.
Ian
x86_64 ABI
my understanding of the x86_64 ABI is that the following structure
should be passed in registers:
struct data {
unsigned int x;
unsigned int y;
unsigned long z;
};
but when I compile:
#include
struct data {
unsigned int x : 32;
unsigned int y : 32;
unsigned long dummy : 64;
} ;
#ifdef __cplusplus
extern "C" int foo (data t);
#else
extern int foo (struct data t);
#endif
#ifndef __cplusplus
struct
#endif
datad;
int
main (int argc, char* argv[])
{
d.x = 1; d.y = 2;
printf ("an integer %d", foo(d));
return 0;
}
I get different results, depending on whether I compile it as C or C+
+ code. I'm using gcc 4.1.1 (but the same happens with 3.4.5).
In C I get:
main:
.LFB12:
subq$8, %rsp
.LCFI0:
movl$1, d+8(%rip)
movl$2, d+12(%rip)
movqd(%rip), %rdi
movqd+8(%rip), %rsi
callfoo
so the argument gets passed in registers.
But in C++ the result is different and the data structure is passed
on the stack.
main:
.LFB13:
subq$24, %rsp
.LCFI0:
movl$1, d+8(%rip)
movqd(%rip), %rdi
movl$2, d+12(%rip)
movqd+8(%rip), %rsi
movq%rdi, (%rsp)
movq%rsi, 8(%rsp)
callfoo
My understanding of the ABI is that the data structure should be
passed in registers, but in any case the behavior should be the same
for C and C++ when data is POD. In the example if foo was a C
function the code produced by g++ would be wrong. In this case it
would also be very dangerous because the data structure happens to be
_also_ in the right registers, but I expect small changes to the code
to make it fail.
Unless g++ is actually passing the argument in registers and what's
wrong is the spurious pushes onto the stack.
Maurizio Vitale
Re: How to insert dynamic code? (continued)
On Jul 13, 2006, at 8:48 AM, jacob navia wrote:
1) I generate exactly the same code now as gcc:
You don't want to generate exactly the same code as gcc, unless it is
exactly the same case; you want to generate the correct code.
Divide and concur.
Do simple things work? For example, do:
routine() {
throw 1;
}
loadme() {
try {
routine();
} catch (...) {
printf("Hello\n");
}
_exit (42);
}
in your JIT language and then compile it, load it and dispatch it.
You can then know if you got there, and if it printed hello and
exited with 42. I'd work on that problem first, if it doesn't work.
Once that works, you know that the right things are registered and
that the information is approximately correct. Repeat the same with
2 layers of functions.
Then you can move onto JITing:
routine() {
throw 1;
}
and call from
void base() {
try {
jit_routine();
} catch (...) {
print("Hello");
}
_exit(42);
}
in normal C++. This checks that yet another part of the problem.
Does that work?
Then, you can add local variables, and print the addresses of the
local variables across throws and ensure that the variable is at the
address you expect after a throw.
void foo() {
int bar [200];
printf("%p\n", bar);
try {...}
catch(...) {
printf("%p\n", bar);
}
}
if they don't have the right values, the frame information isn't yet
correct. Does that work?
Re: How to insert dynamic code? (continued)
On 7/13/06, jacob navia <[EMAIL PROTECTED]> wrote:
Daniel Jacobowitz wrote:
>On Thu, Jul 13, 2006 at 05:06:25PM +0200, jacob navia wrote:
>
>
>>>So, what happens when _Unwind_Find_registered_FDE is called? Does it
>>>find the EH data you have registered?
>>>
>>>
>>>
>>>
>>>
>>Yes but then it stops there instead of going upwards and finding the catch!
>>It is as my insertion left the list of registered routines in a bad state.
>>
>>I will look again at this part (the registering part) and will try to
>>find out what
>>is going on.
>>
>>
>
>It sounds to me more like it used your data, and then was left pointing
>somewhere garbage, not to the next frame. That is, it sounds like
>there's something wrong with your generated unwind tables. That's the
>usual cause for unexpected end of stack.
>
>
>
Yeah...
My fault obviously, who else?
Problem is, there are so mny undocumented stuff that I do not see how I
could
avoid making a mistake here.
1) I generate exactly the same code now as gcc:
Prolog:
push %ebp
movq %rsp,%rbp
subqxxx,%rsp
and I do not touch the stack any more. Nothing is pushed, in the "xxx"
is already the stack
space for argument pushing reserved, just as gcc does. This took me 3
weeks to do.
Now, I write my stuff as follows:
1) CIE
2) FDE for function 1
. 1 fde for each function
3) Empty FDE to zero terminate the stuff.
4) Table of pointers to the CIE, then to the FDE
p = result.FunctionTable; // Starting place, where CIE, then
FDEs are written
p = WriteCIE(p); // Write first the CIE
pFI = DefinedFunctions;
nbOfFunctions=0;
pFdeTable[nbOfFunctions++] = result.FunctionTable;
while (pFI) { // For each function, write the FDE
fde_start = p;
p = Write32(0,p); // reserve place for length field (4
bytes)
p = Write32(p - result.FunctionTable,p); //Write offset
to CIE
symbolP = pFI->FunctionInfo.AssemblerSymbol;
adr = (long long)symbolP->SymbolValue;
adr += (unsigned long long)code_start; // code_start is
the pointer to the Jitted code
p = Write64(adr,p);
p = Write64(pFI->FunctionSize,p); // Write the length in
bytes of the function
*p++ = 0x41;/// Write the opcodes
*p++ = 0x0e; // This opcodes are the same as gcc writes
*p++ = 0x10;
*p++ = 0x86;
*p++ = 0x02;
*p++ = 0x43;
*p++ = 0x0d;
*p++ = 0x06;
p = align8(p);
Write32((p - fde_start)-4,fde_start);// Fix the length
of the FDE
pFdeTable[nbOfFunctions] = fde_start; // Save pointer to
it in table
nbOfFunctions++;
pFI = pFI->Next; // loop
}
The WriteCIE function is this:
static unsigned char *WriteCIE(unsigned char *start)
{
start = Write32(0x14,start);
start = Write32(0,start);
*start++ = 1; // version 1
*start++ = 0; // no augmentation
*start++ = 1;
*start++ = 0x78;
*start++ = 0x10;
*start++ = 0xc;
*start++ = 7;
*start++ = 8;
*start++ = 0x90;
*start++ = 1;
*start++ = 0;
*start++ = 0;
start = Write32(0,start);
return start;
}
I hope this is OK...
jacob
The above code looks incorrect, for various reasons,
not the least of which is that you're assuming CIE/FDE are fixed-length.
There are various factors that affect FDE/CIE
depending on PIC/non-PIC, C or C++, 32bit/64bit, etc -
some of them must be invariant for your JIT but some of them may not.
Also some of the datum are encoded as uleb128
(see dwarf spec for the detail of LEB128 encoding)
which is a variable-length encoding whose length depends on the value.
In short, you'd better start looking at how CIE/FDE structures are *logically*
layed out - otherwise you won't be able to generate correct entries.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
Re: How to insert dynamic code? (continued)
On Thu, Jul 13, 2006 at 11:21:04AM -0700, Seongbae Park wrote: > The above code looks incorrect, for various reasons, > not the least of which is that you're assuming CIE/FDE are fixed-length. > There are various factors that affect FDE/CIE > depending on PIC/non-PIC, C or C++, 32bit/64bit, etc - > some of them must be invariant for your JIT but some of them may not. > Also some of the datum are encoded as uleb128 > (see dwarf spec for the detail of LEB128 encoding) > which is a variable-length encoding whose length depends on the value. > > In short, you'd better start looking at how CIE/FDE structures are > *logically* > layed out - otherwise you won't be able to generate correct entries. I highly highly recommend finding a way to dump your CIE/FDE structures to an ELF file, so that you can use readelf to view them. It is quite accurate and matches the GCC implementation closely. If it can't dump your FDEs, we probably won't unwind through them either. -- Daniel Jacobowitz CodeSourcery
Re: How to insert dynamic code? (continued)
Seongbae Park wrote: The above code looks incorrect, for various reasons, not the least of which is that you're assuming CIE/FDE are fixed-length. This is a trivial thing I will add later. There are various factors that affect FDE/CIE depending on PIC/non-PIC, C or C++, 32bit/64bit, etc - some of them must be invariant for your JIT but some of them may not. I generate always the same prologue for exactly this reason: I do not want to mess with this stuff. Also some of the datum are encoded as uleb128 (see dwarf spec for the detail of LEB128 encoding) which is a variable-length encoding whose length depends on the value. For this values the uleb128 and leb128 routines produce exactly the values shown. In short, you'd better start looking at how CIE/FDE structures are *logically* layed out - otherwise you won't be able to generate correct entries. So far I have understood what those opcodes do, and are the same as gcc. Please try to understand my situation and find the bug ( or where the bug could be). It is not in here? I mean changing *p++ = 1; or p = encodeuleb128(1,p); is *the same* in this context.
gcc-4.0-20060713 is now available
Snapshot gcc-4.0-20060713 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060713/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 115423 You'll find: gcc-4.0-20060713.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060713.tar.bz2 C front end and core compiler gcc-ada-4.0-20060713.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060713.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060713.tar.bz2 C++ front end and runtime gcc-java-4.0-20060713.tar.bz2 Java front end and runtime gcc-objc-4.0-20060713.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060713.tar.bz2The GCC testsuite Diffs from 4.0-20060706 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
campionati mondiale per stragi - la classifica
caro lettore Dopo l'esito dei vincitori dei mondiali di calcio germania 2006 volete sapere chi sono i campioni mondiali per stragi? se ti interessa visita il sito: http://www.elcicala.com il tuo indirizzo e stato preso da elenchi pubblici e se non vuoi ricevere più email dal cicala inviaci un messaggio vuoto e metti nel oggettoi remove o rimuovi.
[PATCH] Install drivers from gcc/Makefile.in
The attached patch moves the basic installation of the compiler drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in has only to inform the driver's name. Additional setup like setting the c++ -> g++ links remains in the Make-lang.in Ok for trunk when stage1 starts? :ADDPATCH build: Best Regards, Rafael 2006-07-13 Rafael Ávila de Espíndola <[EMAIL PROTECTED]> * gcc/java/Make-lang.in (DRIVERS): New (java.install-common): Don't Install the driver * gcc/cp/Make-lang.in (DRIVERS): New (c++.install-common): Don't install the driver * gcc/fortran/Make-lang.in (DRIVERS): New (fortran.install-common): Don't install the driver * gcc/treelang/Make-lang.in (DRIVERS): New (treelang.install.common.done): Don't install the driver * gcc/Makefile.in (DRIVERS): New (LANG_INSTALL_COMMONS): New (install-drivers): New Index: gcc/java/Make-lang.in === --- gcc/java/Make-lang.in (revision 115296) +++ gcc/java/Make-lang.in (working copy) @@ -40,6 +40,8 @@ # - the compiler proper (eg: jc1) # - define the names for selecting the language in LANGUAGES. +DRIVERS += gcj + # Actual names to use when installing a native compiler. JAVA_INSTALL_NAME := $(shell echo gcj|sed '$(program_transform_name)') JAVA_TARGET_INSTALL_NAME := $(target_noncanonical)-$(shell echo gcj|sed '$(program_transform_name)') @@ -199,19 +201,7 @@ check-java : # portable makefiles for both cross builds (where gcjh *must* # be explicitly prefixed) and native builds. java.install-common: installdirs - -if [ -f $(GCJ)$(exeext) ]; then \ - rm -f $(DESTDIR)$(bindir)/$(JAVA_INSTALL_NAME)$(exeext); \ - $(INSTALL_PROGRAM) $(GCJ)$(exeext) $(DESTDIR)$(bindir)/$(JAVA_INSTALL_NAME)$(exeext); \ - chmod a+x $(DESTDIR)$(bindir)/$(JAVA_INSTALL_NAME)$(exeext); \ - if [ -f $(GCJ)-cross$(exeext) ]; then \ - true; \ - else \ - rm -f $(DESTDIR)$(bindir)/$(JAVA_TARGET_INSTALL_NAME)$(exeext); \ - ( cd $(DESTDIR)$(bindir) && \ - $(LN) $(JAVA_INSTALL_NAME)$(exeext) $(JAVA_TARGET_INSTALL_NAME)$(exeext) ); \ - fi ; \ - fi ; \ -for tool in $(JAVA_TARGET_INDEPENDENT_BIN_TOOLS); do \ + for tool in $(JAVA_TARGET_INDEPENDENT_BIN_TOOLS); do \ tool_transformed_name=`echo $$tool|sed '$(program_transform_name)'`; \ if [ -f $$tool$(exeext) ]; then \ rm -f $(DESTDIR)$(bindir)/$$tool_transformed_name$(exeext); \ Index: gcc/cp/Make-lang.in === --- gcc/cp/Make-lang.in (revision 115296) +++ gcc/cp/Make-lang.in (working copy) @@ -37,6 +37,8 @@ # - the compiler proper (eg: cc1plus) # - define the names for selecting the language in LANGUAGES. +DRIVERS += g++ + # Actual names to use when installing a native compiler. CXX_INSTALL_NAME := $(shell echo c++|sed '$(program_transform_name)') GXX_INSTALL_NAME := $(shell echo g++|sed '$(program_transform_name)') @@ -146,25 +148,17 @@ lang_checks += check-g++ # Install the driver program as $(target)-g++ # and also as either g++ (if native) or $(tooldir)/bin/g++. c++.install-common: installdirs - -rm -f $(DESTDIR)$(bindir)/$(GXX_INSTALL_NAME)$(exeext) - -$(INSTALL_PROGRAM) g++$(exeext) $(DESTDIR)$(bindir)/$(GXX_INSTALL_NAME)$(exeext) - -chmod a+x $(DESTDIR)$(bindir)/$(GXX_INSTALL_NAME)$(exeext) -rm -f $(DESTDIR)$(bindir)/$(CXX_INSTALL_NAME)$(exeext) -( cd $(DESTDIR)$(bindir) && \ $(LN) $(GXX_INSTALL_NAME)$(exeext) $(CXX_INSTALL_NAME)$(exeext) ) -if [ -f cc1plus$(exeext) ] ; then \ if [ -f g++-cross$(exeext) ] ; then \ if [ -d $(DESTDIR)$(gcc_tooldir)/bin/. ] ; then \ - rm -f $(DESTDIR)$(gcc_tooldir)/bin/g++$(exeext); \ - $(INSTALL_PROGRAM) g++-cross$(exeext) $(DESTDIR)$(gcc_tooldir)/bin/g++$(exeext); \ rm -f $(DESTDIR)$(gcc_tooldir)/bin/c++$(exeext); \ ( cd $(DESTDIR)$(gcc_tooldir)/bin && \ $(LN) g++$(exeext) c++$(exeext) ); \ else true; fi; \ else \ - rm -f $(DESTDIR)$(bindir)/$(GXX_TARGET_INSTALL_NAME)$(exeext); \ - ( cd $(DESTDIR)$(bindir) && \ - $(LN) $(GXX_INSTALL_NAME)$(exeext) $(GXX_TARGET_INSTALL_NAME)$(exeext) ); \ rm -f $(DESTDIR)$(bindir)/$(CXX_TARGET_INSTALL_NAME)$(exeext); \ ( cd $(DESTDIR)$(bindir) && \ $(LN) $(CXX_INSTALL_NAME)$(exeext) $(CXX_TARGET_INSTALL_NAME)$(exeext) ); \ Index: gcc/fortran/Make-lang.in === --- gcc/fortran/Make-lang.in (revision 115296) +++ gcc/fortran/Make-lang.in (working copy) @@ -40,6 +40,8 @@ # - define the names for selecting the language in LANGUAGES. # $(srcdir) must be set to the gcc/ source directory (*not* gcc/fortran/). +DRIVERS += gfortran + # Actual name to use when installing a native compiler. GFORTRAN_INSTALL_NAME := $(shell echo gfortran|sed '$(program_transform_name)') GFORTRAN_TARGET_INSTALL_NAME := $(target_noncanonical)-$(shell echo gfortran
Re: [PATCH] Install drivers from gcc/Makefile.in
On Jul 14, 2006, at 9:41 AM, Rafael Espíndola wrote: The attached patch moves the basic installation of the compiler drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in has only to inform the driver's name. Additional setup like setting the c++ -> g++ links remains in the Make-lang.in Ok for trunk when stage1 starts? Can you add documentation to the internals manual about this change? Thanks, Andrew Pinski
Re: [PATCH] Install drivers from gcc/Makefile.in
On Thu, Jul 13, 2006 at 09:41:45PM -0300, Rafael Espíndola wrote: > The attached patch moves the basic installation of the compiler > drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in > has only to inform the driver's name. > > Additional setup like setting the c++ -> g++ links remains in the > Make-lang.in > > Ok for trunk when stage1 starts? Please send patches only to the gcc-patches mailing list. TIA. -- Daniel Jacobowitz CodeSourcery
expand_divmod algorithm patented?
PJ has posted a news pick on Groklaw about a new patent which, afar as I can tell, claims the algorithm that Tege has contributed to expmed.c:expand_divmod in 1994 (r7598) http://www.freshpatents.com/Method-and-apparatus-for-efficient-software-based-integer-division-dt20060504ptan20060095494.php
Re: BIT_FIELD_REF on the LHS
On 7/13/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote: Yes, but IIRC that was only for addressable things, not for registers. Changing DECL_COMPLEX_GIMPLE_REG_P to DECL_GIMPLE_REG_P and adding support for it for vector types has fixed this problem. In fact now I can get vec_extract and vec_set (but only if I fix a different issue which checks the mode). Thanks, Andrew Pinski
