Re: porting gcc to new arch: unrecognizable insn
On 01/08/2010 16:26, Gabor Kerenyi wrote: > I'm porting GCC 4.4.4 to a new arch and while cross-compiling libgcc I get > the > following error: > ../../../libgcc/../gcc/libgcc2.c: In function ‘__clzsi2’: > ../../../libgcc/../gcc/libgcc2.c:716: error: unrecognizable insn: > (insn 49 48 50 16 ../../../libgcc/../gcc/libgcc2.c:713 (set (reg:QI 25) > (mem/s/u/j:QI (plus:SI (reg/f:SI 22) > (reg:SI 23)) [0 __clz_tab S1 A8])) -1 (nil)) > ../../../libgcc/../gcc/libgcc2.c:716: internal compiler error: in > extract_insn, at recog.c:2048 > Please submit a full bug report, > > If I understand correctly it complains about a move instruction where src > memory location should be (reg22+reg23). My arch defines: > #define MAX_REGS_PER_ADDRESS 1 > the first pseudo reg is 13 > > So I don't really understand why it tries to use such a pattern. I think the wording of the second sentence in the M_R_P_A documentation (beginning 'Note that ...'): -- Macro: MAX_REGS_PER_ADDRESS A number, the maximum number of registers that can appear in a valid memory address. Note that it is up to you to specify a value equal to the maximum number that `TARGET_LEGITIMATE_ADDRESS_P' would ever accept. ... is meant to imply that you /also/ need to reject such address patterns in TARGET_LEGITIMATE_ADDRESS_P, i.e. M_R_P_A only /informs/ the compiler of the most registers that will be in any address that T_L_A_P ends up accepting, it doesn't set a limit on what the compiler will ask T_L_A_P to decide if it's ok or not. cheers, DaveK
Re: porting gcc to new arch: unrecognizable insn
> > If I understand correctly it complains about a move instruction where src > > memory location should be (reg22+reg23). My arch defines: > > #define MAX_REGS_PER_ADDRESS 1 > > the first pseudo reg is 13 > > > > I think the wording of the second sentence in the M_R_P_A documentation > (beginning 'Note that ...'): > > -- Macro: MAX_REGS_PER_ADDRESS > A number, the maximum number of registers that can appear in a > valid memory address. Note that it is up to you to specify a > value equal to the maximum number that > `TARGET_LEGITIMATE_ADDRESS_P' would ever accept. Yeah I finally found that yesterday. Sorry that I could not find it in the docs before ;) It's open all the time but I just slipped through it... I don't really understand why this define exists anyway if finally only the LEGITIMATE_ADDRESS_P matters. The doc doesn't say (or at least I could not find it) what it is good for, if it is not the decision maker piece. Anyway, the libgcc is cross compiled. The "only" problem I face now that two object files do not compile with -O or -O2 switch. There is an ICE in reload_combine_not_use. But I'll try to figure that out. Thank, Gabor
Restrict qualifier still not working?
Hi,
I ran a small test to see how the trunk/4.5 works
with the rewritten restrict qualified pointer code. But it doesn't
seem to work on both x86-64 and our port.
tst.c:
void foo (int * restrict a, int * restrict b,
int * restrict c, int * restrict d)
{
*c = *a + 1;
*d = *b + 1;
}
tst.c.141r.expand (4.5.0)
;; *c_4(D) = D.2576_3;
(insn 9 8 10 tst2.c:4 (set (reg:SI 67)
(mem:SI (reg/v/f:DI 62 [ a ]) [2 S4 A32])) -1 (nil))
(insn 10 9 11 tst2.c:4 (parallel [
(set (reg:SI 66)
(plus:SI (reg:SI 67)
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) -1 (nil))
(insn 11 10 0 tst2.c:4 (set (mem:SI (reg/v/f:DI 64 [ c ]) [2 S4 A32])
(reg:SI 66)) -1 (expr_list:REG_EQUAL (plus:SI (mem:SI (reg/v/f:DI 62 [
a ]) [2 S4 A32])
(const_int 1 [0x1]))
(nil)))
;; *d_8(D) = D.2578_7;
(insn 12 11 13 tst2.c:5 (set (reg:SI 69)
(mem:SI (reg/v/f:DI 63 [ b ]) [2 S4 A32])) -1 (nil))
(insn 13 12 14 tst2.c:5 (parallel [
(set (reg:SI 68)
(plus:SI (reg:SI 69)
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) -1 (nil))
(insn 14 13 0 tst2.c:5 (set (mem:SI (reg/v/f:DI 65 [ d ]) [2 S4 A32])
(reg:SI 68)) -1 (expr_list:REG_EQUAL (plus:SI (mem:SI (reg/v/f:DI 63 [
b ]) [2 S4 A32])
(const_int 1 [0x1]))
(nil)))
All the memory expression in the RTL have alias set of 2, which
isn't right IMO.
With trunk GCC, memory attribute is represented as:
[2 *a_1(D)+0 S4 A32]. Will the extra *a_1(D)+0 differentiate
alias sets even the number are the same for all MEM expression?
foo:
.LFB0:
.cfi_startproc
movl(%rdi), %eax
addl$1, %eax
movl%eax, (%rdx)
movl(%rsi), %eax
addl$1, %eax
movl%eax, (%rcx)
ret
In the finally generated code, the second load should have
been moved before the first store if restrict qualifiers
are handled correctly.
Am I missing something here? Thanks.
Cheers,
Bingfeng
Re: Restrict qualifier still not working?
On Mon, 2 Aug 2010, Bingfeng Mei wrote:
> Hi,
> I ran a small test to see how the trunk/4.5 works
> with the rewritten restrict qualified pointer code. But it doesn't
> seem to work on both x86-64 and our port.
>
> tst.c:
> void foo (int * restrict a, int * restrict b,
> int * restrict c, int * restrict d)
> {
> *c = *a + 1;
> *d = *b + 1;
> }
[snip]
> foo:
> .LFB0:
> .cfi_startproc
> movl(%rdi), %eax
> addl$1, %eax
> movl%eax, (%rdx)
> movl(%rsi), %eax
> addl$1, %eax
> movl%eax, (%rcx)
> ret
>
> In the finally generated code, the second load should have
> been moved before the first store if restrict qualifiers
> are handled correctly.
>
> Am I missing something here? Thanks.
The second load is moved for me with -fschedule-insns, -frename-registers or
-fselective-scheduling2 (all of which are disabled by default on x86-64 -O2).
Without those flags, second scheduler alone cannot lift the load due to
dependency on %eax.
Hope that helps.
Alexander
Re: xfail syntax
On Mon 2 Aug 2010 10:44, Kilbane, Stephen pondered:
> For #6101, the test's just started failing for 4.3 because 4.3 adds a
> new xfail condition not applied to 4.1:
>
> 4.1: // { dg-do run { xfail sparc*-*-solaris2* } }
> 4.3: // { dg-do run { xfail { { sparc*-*-solaris2* } || lax_strtofp } } }
>
> lax_strtofp just translates as "if target uses uClibc", which explains
> why this test is now PASS for bfin-elf and XPASS for bfin-linux-uclibc
> and bfin-uclinux.
>
> DG/TCL's syntax is defeating me, though. How do I express:
>
> // { dg-do run { xfail { { sparc*-*-solaris2* } ||
> { lax_strtofp && ! bfin-*-* } } }
>
> ?
Thought someone here might know better
DW_AT_external bug 45153 - patch
Hi, please have a look at the Bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153 And a patch(for gcc-4.4.4) posted therein. It seems to fix the issue. Yet, I need to confirm whether DW_AT_external flag should be set for the public functions of a C++ class or not? I guess not, because though public, such functions are not accessible without a class object, unlike regular non-member functions. I'd appreciate your insights about the same. Thank you. --- Regards -P J P PS: Please don't send me html/attachment/Fwd mails
Re: GFDL/GPL issues
On Sat, Jul 31, 2010 at 00:16, Mark Mitchell wrote: > In any case, you're suggesting we go against the express wishes of the > FSF. Would you suggest that we do that in the context of FSF GCC? Well, this issue is another one in a long series of roadblocks that we've had to struggle with over the years. So, eventually, we should seriously consider not being an FSF project anymore. We are already having trouble keeping our documentation up-to-date. Some of it is in such a poor shape as to be laughable. Yes, it's mostly our fault, but if we were able to generate documentation by simply extracting it from the code. Tools exist for this, and properly maintained, they are very useful. SC folks, please find some way of convincing the FSF to stop being unreasonable about this. We are already having a hard time generating good documentation. Why make it harder than it is? Diego.
Re: GFDL/GPL issues
> We are already having trouble keeping our documentation up-to-date. > Some of it is in such a poor shape as to be laughable. Yes, it's > mostly our fault, but if we were able to generate documentation by > simply extracting it from the code. Tools exist for this, and > properly maintained, they are very useful. I disagree and think that's backwards. To get good quality documentation, we have to WRITE good quality documentation. Using tools to generate it from sources will DECREASE its quality, in my opinion. The best measure of quality of a document is how much time people spend writing and editing it.
Re: GFDL/GPL issues
On 10-08-02 19:17 , Richard Kenner wrote: We are already having trouble keeping our documentation up-to-date. Some of it is in such a poor shape as to be laughable. Yes, it's mostly our fault, but if we were able to generate documentation by simply extracting it from the code. Tools exist for this, and properly maintained, they are very useful. I disagree and think that's backwards. To get good quality documentation, we have to WRITE good quality documentation. Using tools to generate it from sources will DECREASE its quality, in my opinion. The best measure of quality of a document is how much time people spend writing and editing it. We'll have to agree to disagree in this respect, then. Notwithstanding our difference of opinions here, the big issue that irritates me is our inability to even attract contributions in this area. Diego.
Re: GFDL/GPL issues
On Tue, Aug 3, 2010 at 1:17 AM, Richard Kenner wrote: >> We are already having trouble keeping our documentation up-to-date. >> Some of it is in such a poor shape as to be laughable. Yes, it's >> mostly our fault, but if we were able to generate documentation by >> simply extracting it from the code. Tools exist for this, and >> properly maintained, they are very useful. > > I disagree and think that's backwards. To get good quality > documentation, we have to WRITE good quality documentation. That is true, but very often the documentation is needed in two places: in the code and in the manual. Especially for things like machine constraints, flags and options. And even if the documentation isn't needed in two places to, well, document something, it may still be useful to automatically generate parts of manual to avoid divergence between the manual and the compiler. But as it is, the good quality documentation cannot be written in the code... Ciao! Steven
Re: GFDL/GPL issues
> That is true, but very often the documentation is needed in two > places: in the code and in the manual. Especially for things like > machine constraints, flags and options. Yes, but the audiences are different between users who read the manual and developers who read the code. For the best quality, the two descriptions may well be quite different, in emphasis, tone and other areas. If the emphasis is on finding text that's acceptable for BOTH purposes, you create documentation that's not ideal for EITHER. > And even if the documentation isn't needed in two places to, well, > document something, it may still be useful to automatically generate > parts of manual to avoid divergence between the manual and the compiler. That's indeed a worthwhile goal, but doing it at the expense of the quality of the documentation is a very bad idea, in my opinion. The quality of documentation in the industry, and even in the Free Software community is pretty poor. GCC is known for a very high standard of documentation. Let's not lower it by substiting automated tools for quality handwritten documentation. I believe that tools have their purpose for such things as functions lists and detailed ABI documentation, but not in things like user manuals.
Re: GFDL/GPL issues
Richard Kenner wrote: >> That is true, but very often the documentation is needed in two >> places: in the code and in the manual. Especially for things like >> machine constraints, flags and options. > > Yes, but the audiences are different between users who read the manual and > developers who read the code. Richard, your argument is a distraction from the important issue at hand. Unless you posit that there is no useful way in which to generate documentation from code (and comments therein), which seems an extreme statement, then it is desirable that we have the ability to do that. Right now we don't. That's bad. I certainly don't disagree that it might be desirable for documentation for constraints might be different for end users and for GCC developers. But, there is nothing that says that both kinds of documentation might not be located physically in the code, so that when you add/delete/modify a constraint you can also easily update the documentation. And, furthermore, just because it might be desirable for the documentation to be different for end-users and compiler developers doesn't mean that it's practical for them to be different. I don't see a mob of people beating down the doors to write GCC documentation. So, I'm not inclined to let perfect be the enemy of good. If we only get one "flavor" of documentation, that's a lot better than none at all! In any case, the key issue here isn't how we should write documentation. It's whether we can use a technological measure to generate documentation if we find cases where that is desirable. It makes no sense for the FSF to artificially erect legal barriers to using a given technical approach to creating documentation. If this is really about documentation quality, the FSF could simply have a policy saying that GNU maintainers should not do this -- there is no reason to have a legal prohibition preventing people from doing it! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
On Aug 2, 2010, at 7:17 PM, Richard Kenner wrote: >> We are already having trouble keeping our documentation up-to-date. >> Some of it is in such a poor shape as to be laughable. Yes, it's >> mostly our fault, but if we were able to generate documentation by >> simply extracting it from the code. Tools exist for this, and >> properly maintained, they are very useful. > > I disagree and think that's backwards. To get good quality > documentation, we have to WRITE good quality documentation. Using > tools to generate it from sources will DECREASE its quality, in my > opinion. The best measure of quality of a document is how much time > people spend writing and editing it. I agree. gcc and gccint docs are actually pretty reasonable. (Certainly gccint is vastly better than some of its siblings, like gdbint.) But very little of it is generated and very little of what comes to mind as possible subject matter is suitable for being generated. Even when things have been set up from the start for generating documentation (like embedded documentation strings in Python code) such "documentation" rarely captures more than trivial information about calling conventions. Nothing of substance ever comes from documentation of that kind. paul
Re: GFDL/GPL issues
> Richard, your argument is a distraction from the important issue at > hand. Unless you posit that there is no useful way in which to generate > documentation from code (and comments therein), which seems an extreme > statement, then it is desirable that we have the ability to do that. > Right now we don't. That's bad. "bad" isn't very precise. The claim was made that a reason that it's "bad" is that not being able to automatically generate documentation lowers the quality of the documentation. That's what I disagree with. > But, there is nothing that says that both kinds of documentation might > not be located physically in the code, so that when you > add/delete/modify a constraint you can also easily update the > documentation. In that case, wouldn't we have two distinctly different kinds of material in the same file: an extract from a manual and code. So why couldn't the file have a license that says "this part is GFDL and this part is GPL"?
Re: GFDL/GPL issues
Richard Kenner wrote: > "bad" isn't very precise. The claim was made that a reason that it's "bad" > is that not being able to automatically generate documentation lowers > the quality of the documentation. That's what I disagree with. OK, fine; that's a reasonably debatable point. But, we currently can't automatically generate manuals -- which is something we used to be able to do -- and that's bad. In general, a policy that prevents us from being able to use a particular technical method to achieve a goal is silly. >> But, there is nothing that says that both kinds of documentation might >> not be located physically in the code, so that when you >> add/delete/modify a constraint you can also easily update the >> documentation. > > In that case, wouldn't we have two distinctly different kinds of material > in the same file: an extract from a manual and code. So why couldn't > the file have a license that says "this part is GFDL and this part is GPL"? Maybe it could. But, maybe it can't. It depends on how closely you can weave the documents together before you end up with something that is more than mere aggregation. None of this really answers the key question, which is, in my opinion, what is the GFDL actually buying us? And, if all it's buying us is that people can't remove the FSF's philosophical statements in manuals, is that worth having to split hairs about exactly what parts of what documentation can be generated in what exact manner? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
How to get attual method in GCC AST
I am work on a project related with GCC AST.
In my project, i write a plugin for GCC. This plugin read a AST from a
source code, a covert this source code to another language.
Currently i have a problem with GCC AST. In particular, i cannot
retrieve all information about CALL_EXPR.
I read GCC internal, and i have known about structure of CALL_EXPR node in GCC.
But when i have a source code
class A{
public:
virtual void read();
};
class B : A {
public:
int a;
void read() {}
};
class D {
public:
void test() {
B *b;
b->read();
}
};
int main(int argc, char** argv) {
D d;
d.test();
}
This is AST of method test in class D i got:
bind_expr (test.cpp:21-18)
statement_list
decl_expr (test.cpp:20-12)
var_decl : b (B *) (test.cpp :20)
cleanup_point_expr (test.cpp:21-18)
expr_stmt (test.cpp:21-18)
call_expr (test.cpp:21-17)
obj_type_ref
indirect_ref (test.cpp:21-17)
non_lvalue_expr (test.cpp:21-17)
component_ref
component_ref
indirect_ref
non_lvalue_expr
var_decl : b (B *) (test.cpp :20)
field_decl : internal hidden (unknown type) (test.cpp :9)
field_decl : _vptr.A (int * *) (test.cpp :4)
non_lvalue_expr
var_decl : b (B *) (test.cpp :20)
integer_cst 0
non_lvalue_expr
var_decl : b (B *) (test.cpp :20)
The problem is method read() of class B is get from a virtual method
of based class A. And i cannot get the real name of this method.
Do you have any ideal to help me. Thansk
