Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
I'm not dependent on it, although at some point, I'm sure i may take a closer look at the code to see how they've done certain things. Just as a reminder, even though the Microchip code is covered by the GPL, code based on it >>won't be acceptable for inclusion into FSF GCC unless you can get Microchip to sign a copyright >>assignment, which seems unlikely. Would seem to be easy enough to do, just, one cannot count on it. People that want to start >from that code should open a dialogue now, before they start.
Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
I'm not quite sure I follow you.. if its possible to dedicate a register to act as the data-stack pointer, and implement it that way, why would I want to "keep the SP as a virtual register"? I'm not being antagonistic when I say that.. I'm just trying to understand what you're trying to tell me.. Will check out the ip2k port again.. the last time I looked, I was blinded by the assumption that if the usual stack macros were defined in a straightforward fashion, that the target actually supported (or implemented) a stack... "It ain't necessarily so". you might be able to keep the SP as a virtual register and make sure that code generation never tries to actually use it
RE: GCC Port (gcc backend) for Microchip PICMicro microcontroller
On 11 April 2006 08:47, Colm O' Flaherty wrote: > I'm not quite sure I follow you.. if its possible to dedicate a register to > act as the data-stack pointer, and implement it that way, why would I want > to "keep the SP as a virtual register"? Because then you would /not/ have to sacrifice one of your precious limited supply of registers to act as a real hard stack pointer and it would be used as a general purpose register instead and allow better code generatation and less spilling when the register pressure gets high. cheers, DaveK -- Can't think of a witty .sigline today
RE: Posts don't appear on the gcc mailing list...
On 11 April 2006 02:34, Mark Cuss wrote: > Hello > > I've subscribed to the gcc mailing list from my work account > ([EMAIL PROTECTED]) but none of my posts appear on the mailing > list... Ok. point one: > The mail doesn't get bounced back so I assume it's getting > delivered, That's a false assumption. > but nonetheless my posts don't show up on the list... That's strong evidence in favour of believing the previous assumption to be false. > Is there someone who can give me a hand with this? Probably you can, as it happens! The sourceware.org lists are set up so that every message that is rejected generates a bounce, and every message that is not rejected is forwarded to the list and posted to the archive. Although it is conceivable that your posts could have been lost in between being received and being forwarded, everyone else's posts are going through fine, and any such glitch or bug is unlikely to depend so precisely on the sender, so the most likely theory is that your posts are getting rejected for some reason, and that for some other reason you are just not /seeing/ the bounce messages that explain why your posts were rejected. Go to your spambin, and take a look through it, and I reckon you'll find the bounce messages that explain why your posts were rejected. If you really can't find any sign of any bounces, reply to this post, Cc'ing both me and the list, and I'll see if I can see any problems with your message format The most obvious one - are you sending HTML? That's against list policy. See http://gcc.gnu.org/lists.html for the full details. cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC Compiler Engineer job (I am not a recruiter)
Florian Weimer wrote: * Mark Mitchell: 1. What do we do if people do advertise jobs that are not free software jobs, or not purely free software jobs? How pure is pure? Does "Port GCC to proprietary OS" count as free or not? And: Does porting GCC to a new processor, to run on a free operating system, without ever publishing the port qualify as free software? Sure it does, there is no requirement to publish Free Software (if there were such a requirement, it would not be Free Software any more).
Re: GCC Compiler Engineer job (I am not a recruiter)
On Mon, 10 Apr 2006, Mark Mitchell wrote: > It seems like we're getting consensus around that approach, despite the > initial sentiment in the other direction from Mike and Joe. Mike, Joe, > do either of you care to argue the point? If not, I'll volunteer to > write some text for the web pages, and ask Gerald to find a place to put it. http://gcc.gnu.org/lists.html probably would be the best place for such a note. Personally, I'd be in favor of GCC-releated internships and job offers on our lists, but I see that it may be difficult to draw a line. That said, I wonder how to handle .signatures: for example, if you added a line like "CodeSourcery is hiring. http://.../work4us/";, wouldn't that be okay? Gerald
Re: traverse the gimple tree
Hello,
> I want to write a pass to walk the gimple tree and add some intrumentation
> code. I read the chapter 9 of "GCC Internals" document, and it seems not to
> describe the Macros to do so.
>
> Can I get some information about this? Specifically, if someone can show me
> which .h file I should look at to find the Macros, that would be great. Or,
> Is there any other pass do the similar thing(traverse the gimple tree) that
> I can read (--I did not find)?
depending on what you need, you may use walk_tree and/or combination of
special-handling for structured statements and tsi_ iterators, at that
point. See e.g. pass_lower_cf.
Zdenek
>
> //in gcc.4.0.2, tree-optimize.c
>323 void
>324 init_tree_optimization_passes (void)
>325 {
>326 struct tree_opt_pass **p;
>327
>328 #define NEXT_PASS(PASS) (p = next_pass_1 (p, &PASS))
>329
>330 p = &all_passes;
>331 NEXT_PASS (pass_gimple);
>332
>333 NEXT_PASS (MYPASS_code_instrument); //this is what I want to do
>334 //the reason I want to add the pass here is: both C/C++(any other
> front end, later) can use this;
>335 NEXT_PASS (pass_remove_useless_stmts);
>336 NEXT_PASS (pass_mudflap_1);
>337 NEXT_PASS (pass_lower_cf);
>338 NEXT_PASS (pass_lower_eh);
>339 NEXT_PASS (pass_build_cfg);
> ..
> }
>
>
> _
> Express yourself instantly with MSN Messenger! Download today - it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
Re: duplicate_block weirdness
Hello,
> Dear mailing list,
>
> is there something wrong with the following code?
> --
> basic_block my_basic_block;
> basic_block dup_basic_block;
>
> FOR_EACH_BB(my_basic_block)
> {
> dup_basic_block = duplicate_block(bb, NULL);
> }
I assume you mean
> dup_basic_block = duplicate_block(my_basic_block, NULL);
Then, this code is quite likely to cause an infinite loop, duplicating
also the newly created basic blocks. I however have no idea how this
could cause the ICE you describe below.
Zdenek
> --
> I get an ICE in get_indirect_ref_operands, with the backtrace:
> --
> #0 0x000100175688 in get_indirect_ref_operands
> (stmt=0x7ea0c640, expr=0x7eaf8100, flags=0)
> at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:1417
> #1 0x000100173dcc in get_expr_operands (stmt=0x7ea0c640,
> expr_p=0x7ea0c3f8, flags=0)
> at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:1091
> #2 0x00010017406c in get_expr_operands (stmt=0x7ea0c640,
> expr_p=0x7ea0c680, flags=0)
> at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:1134
> #3 0x000100172f94 in build_ssa_operands
> (stmt=0x7ea0c640, ann=0x7eaf6850,
> old_ops=0x7fffcd90,
> new_ops=0x7eaf6878) at ../../gcc-4.0.1/gcc/tree-ssa-
> operands.c:906
> #4 0x000100173b20 in get_stmt_operands (stmt=0x7ea0c640)
> at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:1021
> #5 0x00010010ca18 in tree_duplicate_bb (bb=0x7eafbe10)
> at ../../gcc-4.0.1/gcc/tree-cfg.c:4684
> #6 0x000100591ea8 in duplicate_block (bb=0x7eafbe10,
> e=0x0) at ../../gcc-4.0.1/gcc/cfghooks.c:717
> ...
> --
> The context is a tree optimization pass, with PROP_gimple_any |
> PROP_ssa | PROP_cfg | PROP_referenced_vars required.
>
> Sincerely,
> Sean Callanan
Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
On Apr 11, 2006, at 03:46, Colm O' Flaherty wrote: I'm not quite sure I follow you.. if its possible to dedicate a register to act as the data-stack pointer, and implement it that way, why would I want to "keep the SP as a virtual register"? I'm not being antagonistic when I say that.. I'm just trying to understand what you're trying to tell me.. Sorry, thought you were indicating that you didn't WANT a data stack :-) Now I understand that your chip just doesn't provide hardware support for stacks. BTW, another port I did (to a RISCy architecture that was the core for a high-speed multiprotocol router (never submitted to the FSF and the company's now belly-up) provides a "lower bound" on how simple an addressing scheme you can deal with. This machine had 512 directly addressable memory locations and 4 registers that could be indirected thru (kinda like the way the PDP-8 worked). With 3 registers available for reload (1 was reserved for the SP), you could pretty much compile all the GCC test suite that didn't need more than 512 words of memory. [Oh, BTW, chars were 32 bits on this machine also] Will check out the ip2k port again.. the last time I looked, I was blinded by the assumption that if the usual stack macros were defined in a straightforward fashion, that the target actually supported (or implemented) a stack... "It ain't necessarily so". you might be able to keep the SP as a virtual register and make sure that code generation never tries to actually use it
Re: GCC Compiler Engineer job (I am not a recruiter)
Mark Mitchell <[EMAIL PROTECTED]> writes: | Mike Stump wrote: | | >> 3. How do we enforce any of these rules? | > | > Shame on those that violate them. | | I think we need to do better than that. I'll vote for keeping the current policy: not job ads on the development list. -- Gaby
Re: traverse the gimple tree
Thanks,
Can you give me a hint of the three following fields? Some passes defined
them (such as pass_lower_cf), but soem passes leave them as NULL/0.
Thanks,
37 struct tree_opt_pass
38 {
63 /* Sets of properties input and output from this pass. */
64 unsigned int properties_required; //
65 unsigned int properties_provided;
66 unsigned int properties_destroyed;
..}
pass_lower_cf defined them as
135 PROP_gimple_any, /* properties_required */
136 PROP_gimple_lcf, /* properties_provided */
137 PROP_gimple_any, /* properties_destroyed */
From: Zdenek Dvorak <[EMAIL PROTECTED]>
To: sean yang <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org
Subject: Re: traverse the gimple tree
Date: Tue, 11 Apr 2006 13:56:48 +0200
Hello,
> I want to write a pass to walk the gimple tree and add some
intrumentation
> code. I read the chapter 9 of "GCC Internals" document, and it seems not
to
> describe the Macros to do so.
>
> Can I get some information about this? Specifically, if someone can show
me
> which .h file I should look at to find the Macros, that would be great.
Or,
> Is there any other pass do the similar thing(traverse the gimple tree)
that
> I can read (--I did not find)?
depending on what you need, you may use walk_tree and/or combination of
special-handling for structured statements and tsi_ iterators, at that
point. See e.g. pass_lower_cf.
Zdenek
>
> //in gcc.4.0.2, tree-optimize.c
>323 void
>324 init_tree_optimization_passes (void)
>325 {
>326 struct tree_opt_pass **p;
>327
>328 #define NEXT_PASS(PASS) (p = next_pass_1 (p, &PASS))
>329
>330 p = &all_passes;
>331 NEXT_PASS (pass_gimple);
>332
>333 NEXT_PASS (MYPASS_code_instrument); //this is what I want to do
>334 //the reason I want to add the pass here is: both C/C++(any
other
> front end, later) can use this;
>335 NEXT_PASS (pass_remove_useless_stmts);
>336 NEXT_PASS (pass_mudflap_1);
>337 NEXT_PASS (pass_lower_cf);
>338 NEXT_PASS (pass_lower_eh);
>339 NEXT_PASS (pass_build_cfg);
> ..
> }
>
>
> _
> Express yourself instantly with MSN Messenger! Download today - it's
FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
_
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
Re: GCC Compiler Engineer job (I am not a recruiter)
Gerald Pfeifer wrote: > Personally, I'd be in favor of GCC-releated internships and job offers on > our lists, but I see that it may be difficult to draw a line. That said, > I wonder how to handle .signatures: for example, if you added a line like > "CodeSourcery is hiring. http://.../work4us/";, wouldn't that be okay? We (the SC/FSF) could decide that's not OK. We already tell people the signatures generated by their IT departments regarding confidentiality are not OK, and most people have more control of their personal signatures than what their IT department does. I'm OK with any outcome here, but if we're moving towards "no ads" then I'd just suggest we make it an absolute requirement, as that's clearest. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
gcc 3.4.4 build fails on Solaris (SPARC): Unable to run C Compiled Programs
Hello I'm trying to build gcc 3.4.4 on a sparc machine running Solaris 9. My build setup was: ../gcc-3.4.4/configure --diabled-shared --prefix=dir> --enable-languages=c,c++ make bootstrap (the install dir is the same directory which I previously compiled and installed binutils into) I'm attempting the build with gcc-3.3.3 The error message is: make[5]: Entering directory `/cdl/apps/.software/sun/gcc-3.4.4-toolchain-build/build-gcc/sparc-sun-solaris2.9/sparcv9/libstdc++-v3' make[5]: *** No rule to make target `all'. Stop. make[5]: Leaving directory `/cdl/apps/.software/sun/gcc-3.4.4-toolchain-build/build-gcc/sparc-sun-solaris2.9/sparcv9/libstdc++-v3' make[4]: *** [multi-do] Error 1 make[4]: Leaving directory `/cdl/apps/.software/sun/gcc-3.4.4-toolchain-build/build-gcc/sparc-sun-solaris2.9/libstdc++-v3' make[3]: *** [all-multi] Error 2 make[3]: Leaving directory `/cdl/apps/.software/sun/gcc-3.4.4-toolchain-build/build-gcc/sparc-sun-solaris2.9/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/cdl/apps/.software/sun/gcc-3.4.4-toolchain-build/build-gcc/sparc-sun-solaris2.9/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/cdl/apps/.software/sun/gcc-3.4.4-toolchain-build/build-gcc' make: *** [bootstrap] Error 2 [EMAIL PROTECTED] build-gcc]$ (config.log is below) I've googled on this problem - it seems that others have had similar problems with gcc 3.4.x on sparc. There was a post on the gcc-help list with no reply, and several other references around the web as well but none with solutions. I'd really appreciate it if someone could point me in the right direction on this one... Do I need a patch for gcc 3.4.4 to build on sparc? Thanks Mark --- config.log --- his file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:581: checking host system type configure:602: checking target system type configure:620: checking build system type configure:675: checking for a BSD compatible install configure:2866: checking for sparc-sun-solaris2.9-ar configure:2899: checking for ar configure:2938: checking for sparc-sun-solaris2.9-as configure:2971: checking for as configure:3010: checking for sparc-sun-solaris2.9-dlltool configure:3043: checking for dlltool configure:3082: checking for sparc-sun-solaris2.9-ld configure:3154: checking for sparc-sun-solaris2.9-nm configure:3187: checking for nm configure:3226: checking for sparc-sun-solaris2.9-ranlib configure:3259: checking for ranlib configure:3298: checking for sparc-sun-solaris2.9-windres configure:3331: checking for windres configure:3370: checking for sparc-sun-solaris2.9-objcopy configure:3403: checking for objcopy configure:3442: checking for sparc-sun-solaris2.9-objdump configure:3475: checking for objdump configure:3524: checking for sparc-sun-solaris2.9-ar configure:3557: checking for ar configure:3596: checking for sparc-sun-solaris2.9-as configure:3629: checking for as configure:3668: checking for sparc-sun-solaris2.9-dlltool configure:3701: checking for dlltool configure:3740: checking for sparc-sun-solaris2.9-ld configure:3773: checking for ld configure:3812: checking for sparc-sun-solaris2.9-nm configure:3845: checking for nm configure:3884: checking for sparc-sun-solaris2.9-ranlib configure:3917: checking for ranlib configure:3956: checking for sparc-sun-solaris2.9-windres configure:3989: checking for windres configure:4056: checking whether to enable maintainer-specific portions of Makefiles Mark Cuss, B. Sc. Software Developer Systems Administrator CDL Systems Ltd. Suite 220 3553 31 Street NW Calgary, AB, Canada T2L 2K7 Phone 403 289 1733 ext 226 Fax 403 289 3967 [EMAIL PROTECTED] www.cdlsystems.com
Re: gcc 3.4.4 build fails on Solaris (SPARC): Unable to run C Compiled Programs
> I'm trying to build gcc 3.4.4 on a sparc machine running Solaris 9. My > build setup was: > ../gcc-3.4.4/configure --diabled-shared --prefix= dir> --enable-languages=c,c++ > make bootstrap I see 4 potential problems: - do not use a relative path to configure, - "--diabled-shared" is probably not what you intended, - is the "make" in "make bootstrap" a recent version of GNU make? - does your kernel support 64-bit? If not, you need to configure with --disable-multilib. > I'd really appreciate it if someone could point me in the right direction > on this one... Do I need a patch for gcc 3.4.4 to build on sparc? Nope, but please read the instructions carefully: http://gcc.gnu.org/install/specific.html#x-x-solaris2 -- Eric Botcazou
Re: gcc 3.4.4 build fails on Solaris (SPARC): Unable to run C Compiled Programs
Thanks Eric I thought it was OK to use a relative path. From what I understood, it is a bad idea to build inside the directory that the gcc tar file is uncompressed into, but I guess I can specifiy the path in full. Definitely a typo in the email on the disable shared thing I'm using GNU make version 3.80 I'm quite sure the kernel supports 64 bit - I've never had to disable anything for that before to get previous versions to build on sparc... Thanks Mark - Original Message - From: "Eric Botcazou" <[EMAIL PROTECTED]> To: "Mark Cuss" <[EMAIL PROTECTED]> Cc: Sent: Tuesday, April 11, 2006 10:22 AM Subject: Re: gcc 3.4.4 build fails on Solaris (SPARC): Unable to run C Compiled Programs I'm trying to build gcc 3.4.4 on a sparc machine running Solaris 9. My build setup was: ../gcc-3.4.4/configure --diabled-shared --prefix= --enable-languages=c,c++ make bootstrap I see 4 potential problems: - do not use a relative path to configure, - "--diabled-shared" is probably not what you intended, - is the "make" in "make bootstrap" a recent version of GNU make? - does your kernel support 64-bit? If not, you need to configure with --disable-multilib. I'd really appreciate it if someone could point me in the right direction on this one... Do I need a patch for gcc 3.4.4 to build on sparc? Nope, but please read the instructions carefully: http://gcc.gnu.org/install/specific.html#x-x-solaris2 -- Eric Botcazou
Re: gcc 3.4.4 build fails on Solaris (SPARC): Unable to run C Compiled Programs
> I thought it was OK to use a relative path. From what I understood, it is > a bad idea to build inside the directory that the gcc tar file is > uncompressed into, but I guess I can specifiy the path in full. Yes, and while you are at it, use the recommended config shell. -- Eric Botcazou
i read that i should send here email
I try compile example program gcc.exe -I"c:\gcc\include" -L"c:\gcc\lib" c:\gcc\bin\program.c gcc.exe: Internal error: (null) (program as) Please submit bug report. Free is bad? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: duplicate_block weirdness
Yes, I meant
--
basic_block my_basic_block;
basic_block dup_basic_block;
FOR_EACH_BB(my_basic_block)
{
dup_basic_block = duplicate_block(my_basic_block, NULL);
}
--
I also got some more precise context. The statement being copied at
that point is:
--
*D.1600 = 0;
--
whose GIMPLE representation looks like this:
--
MODIFY_EXPR (2)
INDIRECT_REF (1)
VAR_DECL(0)
INTEGER_CST(0)
--
where the number in parentheses is the number of operands. The
backtrace below:
--
#0 0x000100175688 in get_indirect_ref_operands
(stmt=0x7ea0c640, expr=0x7eaf8100, flags=0)
at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:1417
#1 0x000100173dcc in get_expr_operands
(stmt=0x7ea0c640, expr_p=0x7ea0c3f8, flags=0)
at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:1091
#2 0x00010017406c in get_expr_operands
(stmt=0x7ea0c640, expr_p=0x7ea0c680, flags=0)
at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:1134
#3 0x000100172f94 in build_ssa_operands
(stmt=0x7ea0c640, ann=0x7eaf6850,
old_ops=0x7fffcd90, new_ops=0x7eaf6878)
at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:906
#4 0x000100173b20 in get_stmt_operands (stmt=0x7ea0c640)
at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:1021
#5 0x00010010ca18 in tree_duplicate_bb (bb=0x7eafbe10)
at ../../gcc-4.0.1/gcc/tree-cfg.c:4684
#6 0x000100591ea8 in duplicate_block (bb=0x7eafbe10,
e=0x0)
at ../../gcc-4.0.1/gcc/cfghooks.c:717
...
--
is from an ICE:
- get_expr_operands() on the INDIRECT_REF calls
get_indirect_ref_operands(), and
- get_indirect_ref_operands() tries to look at the var_ann for the
INDIRECT_REF, which is NULL at that point.
Is the var_ann NULL because I need to require something more than
PROP_gimple_any | PROP_ssa | PROP_cfg | PROP_referenced_vars, or is
there something else going on here?
Sincerely,
Sean Callanan
Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
I send a message to John Elliott's listed address yesterday, and I have not yet received an immediate response. I will post to this list if I receive anything from him. So, I'd caution anyone away from basing any work on the dsPIC port until some specific understanding is established with Microchip--if you want it to be included in FSF GCC.
Re: gcc 3.4.4 build fails on Solaris (SPARC): Unable to run C Compiled Programs
Ok - it built this time. I guess I should read the instructions - my fault... Thanks for the help! Mark - Original Message - From: "Eric Botcazou" <[EMAIL PROTECTED]> To: "Mark Cuss" <[EMAIL PROTECTED]> Cc: Sent: Tuesday, April 11, 2006 10:52 AM Subject: Re: gcc 3.4.4 build fails on Solaris (SPARC): Unable to run C Compiled Programs I thought it was OK to use a relative path. From what I understood, it is a bad idea to build inside the directory that the gcc tar file is uncompressed into, but I guess I can specifiy the path in full. Yes, and while you are at it, use the recommended config shell. -- Eric Botcazou
Re: duplicate_block weirdness
is from an ICE: - get_expr_operands() on the INDIRECT_REF calls get_indirect_ref_operands(), and - get_indirect_ref_operands() tries to look at the var_ann for the INDIRECT_REF, which is NULL at that point. Is the var_ann NULL because I need to require something more than PROP_gimple_any | PROP_ssa | PROP_cfg | PROP_referenced_vars, or is there something else going on here? var_ann is null because you are trying to insert your pass before the annotations are set up. Move your pass so it is after pass_referenced_vars, at the least. Sincerely, Sean Callanan
Re: GCC Compiler Engineer job (I am not a recruiter)
On Apr 10, 2006, at 4:30 PM, Mark Mitchell wrote: It seems like we're getting consensus around that approach, despite the initial sentiment in the other direction from Mike and Joe. Mike, Joe, do either of you care to argue the point? I'm fine with the status quo. I think comp.compilers and fsf.org/ jobs are decent and reasonable.
Re: Boehm GC memory leak on Darwin
Thanks Sandro, I have checked this in to the trunk and the 4.1 branch.
It would be great to get a copyright assignment form from you so that we
can check in the rest of your Darwin/x86 patches. Have you started the
copyright assignment process? If not, the form to do so can be found here:
http://gcc.gnu.org/ml/gcc/2003-06/msg02298.html
Bryce
Sandro Tolaini wrote:
I'm sending this note again since I have been caught in this bug once
more. Under Darwin (PPC and Intel) there is a serious memory leak at
every Boehm GC cycle. See discussion and patch here:
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2005-December/001071.html
I think that the patch should be applied to every maintained branch.
Please maintainers, check this in!
2006-04-11 Bryce McKinlay <[EMAIL PROTECTED]>
* darwin_stop_world.c (GC_push_all_stacks, GC_stop_world,
GC_start_world): Call vm_deallocate to free act_list. Fix from
Bruce Mitchener.
Index: darwin_stop_world.c
===
--- darwin_stop_world.c (revision 112716)
+++ darwin_stop_world.c (working copy)
@@ -155,6 +155,7 @@
# endif
GC_push_all_stack(lo, hi);
} /* for(p=GC_threads[i]...) */
+vm_deallocate(current_task(), (vm_address_t)act_list, sizeof(thread_t) * listcount);
}
static mach_port_t GC_mach_handler_thread;
@@ -297,6 +298,7 @@
changes = result;
prev_list = act_list;
prevcount = listcount;
+vm_deallocate(current_task(), (vm_address_t)act_list, sizeof(thread_t) * listcount);
} while (changes);
@@ -368,6 +370,7 @@
}
}
}
+vm_deallocate(current_task(), (vm_address_t)act_list, sizeof(thread_t) * listcount);
# if DEBUG_THREADS
GC_printf0("World started\n");
# endif
Re: [RFC] Ignore TREE_CONSTANT_OVERFLOW in integer_zerop
Roger Sayle wrote: > such a step. Is such a transition safe for stage 3 mainline, > and/or would front-ends prefer some time to double check that > this won't cause problems on conformance tests not part of GCC's > testsuite. I think it's reasonable to make this change at this point, as there are real bugs that you're fixing. Please do be careful, and please confine the changes to those that actually fix bugs, rather than just clean-ups for clean-up sake. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC intrinsics for the MPC8540 architecture
Hi,
First I apologize, if this is the wrong list. :)
I hope someone from the developer's group can't point me in the right
direction? I did not get a response on GCC-help list.
I am trying to compile code that uses the
vector processor (SPE) found on the E500 (i.e. MPC8540)
I am using the SPE Programming Instruction Manual (SPEPIM.pdf)
There is a mailing list for ALTIVEC but not for SPE?
I get the following error when trying to print some basic tests:
=
error: incompatible type for argument 1 of `__ev_get_u32_internal'
=
Here is a code snippet:
===
#include
#include
void spe_print_test()
{
__ev64_u32__ v = {0x4000, 0x2000};
printf ("%R %R\n", __ev_get_upper_ufix32_u32(v),
__ev_get_lower_ufix32_u32(v));
printf ("%r %r\n", __ev_get_upper_ufix32_u32(v),
__ev_get_lower_ufix32_u32(v));
printf ("%04R %04R\n", __ev_get_upper_ufix32_u32(v),
__ev_get_lower_ufix32_u32(v));
printf ("%04r %04r\n", __ev_get_upper_ufix32_u32(v),
__ev_get_lower_ufix32_u32(v));
}
question about treelang modification and debug
hi,
You know that treelang prescribes the function prototype must give the
storage class type explicitly, for an example, "external_definition
int add(int arg1, int arg2);"
I'd like to know how to modify the parse.y to let the storage type can
be implicitly and the default type is external_definition. Here is my
modification, but it's wrong, and bring the gcc into internal compiler
error. Can anyone give any suggestion? And I also want to how to debug
the modification.
Thanks.
Here is original code,---
function_prototype:
storage typename NAME LEFT_PARENTHESIS parameters RIGHT_PARENTHESIS SEMICOLON {
struct prod_token_parm_item* tok;
struct prod_token_parm_item *prod;
struct prod_token_parm_item *type;
struct prod_token_parm_item* first_parms;
struct prod_token_parm_item* last_parms;
struct prod_token_parm_item* this_parms;
struct prod_token_parm_item *this_parm;
struct prod_token_parm_item *this_parm_var;
tok = $3;
prod = make_production (PROD_FUNCTION_NAME, $3);
SYMBOL_TABLE_NAME (prod) = $3;
EXPRESSION_TYPE (prod) = $2;
NUMERIC_TYPE (prod) = NUMERIC_TYPE (( (struct
prod_token_parm_item*)EXPRESSION_TYPE (prod)));
PARAMETERS (prod) = reverse_prod_list ($5);
insert_tree_name (prod);
STORAGE_CLASS_TOKEN (prod) = $1;
set_storage (prod);
switch (STORAGE_CLASS (prod))
{
case STATIC_STORAGE:
case EXTERNAL_DEFINITION_STORAGE:
break;
case AUTOMATIC_STORAGE:
fprintf (stderr, "%s:%i:%i: A function cannot be automatic\n",
tok->tp.tok.location.file,
tok->tp.tok.location.line, tok->tp.tok.charno);
print_token (stderr, 0, tok);
errorcount++;
YYERROR;
break;
default:
abort ();
}
type = EXPRESSION_TYPE (prod);
/* Create a parameter list in a non-front end specific format. */
for (first_parms = NULL, last_parms = NULL, this_parm = PARAMETERS (prod);
this_parm;
this_parm = this_parm->tp.pro.next)
{
if (this_parm->category != production_category)
abort ();
this_parm_var = VARIABLE (this_parm);
if (!this_parm_var)
abort ();
if (this_parm_var->category != production_category)
abort ();
this_parms = my_malloc (sizeof (struct prod_token_parm_item));
if (!this_parm_var->tp.pro.main_token)
abort ();
this_parms->tp.par.variable_name =
this_parm_var->tp.pro.main_token->tp.tok.chars;
this_parms->category = parameter_category;
this_parms->type = NUMERIC_TYPE
(( (struct prod_token_parm_item*)EXPRESSION_TYPE (this_parm_var)));
if (last_parms)
{
last_parms->tp.par.next = this_parms;
last_parms = this_parms;
}
else
{
first_parms = this_parms;
last_parms = this_parms;
}
this_parms->tp.par.where_to_put_var_tree =
& (( (struct prod_token_parm_item*)VARIABLE (this_parm))->tp.pro.code);
}
FIRST_PARMS (prod) = first_parms;
prod->tp.pro.code = tree_code_create_function_prototype
(tok->tp.tok.chars, STORAGE_CLASS (prod), NUMERIC_TYPE (type),
first_parms, tok->tp.tok.location);
}
;
Here is my code,--
function_prototype:
storage typename NAME LEFT_PARENTHESIS parameters RIGHT_PARENTHESIS SEMICOLON {
struct prod_token_parm_item* tok;
struct prod_token_parm_item *prod;
struct prod_token_parm_item *type;
struct prod_token_parm_item* first_parms;
struct prod_token_parm_item* last_parms;
struct prod_token_parm_item* this_parms;
struct prod_token_parm_item *this_parm;
struct prod_token_parm_item *this_parm_var;
tok = $3;
prod = make_production (PROD_FUNCTION_NAME, $3);
SYMBOL_TABLE_NAME (prod) = $3;
EXPRESSION_TYPE (prod) = $2;
NUMERIC_TYPE (prod) = NUMERIC_TYPE (( (struct
prod_token_parm_item*)EXPRESSION_TYPE (prod)));
PARAMETERS (prod) = reverse_prod_list ($5);
insert_tree_name (prod);
STORAGE_CLASS_TOKEN (prod) = $1;
set_storage (prod);
switch (STORAGE_CLASS (prod))
{
case STATIC_STORAGE:
case EXTERNAL_DEFINITION_STORAGE:
break;
case AUTOMATIC_STORAGE:
fprintf (stderr, "%s:%i:%i: A function cannot be automatic\n",
tok->tp.tok.location.file,
tok->tp.tok.location.line, tok->tp.tok.charno);
print_token (stderr, 0, tok);
errorcount++;
YYERROR;
break;
default:
abort ();
}
type = EXPRESSION_TYPE (prod);
/* Create a parameter list in a non-front end specific format. */
for (first_parms = NULL, last_parms = NULL, this_parm = PARAMETERS (prod);
this_parm;
this_parm = this_parm->tp.pro.next)
{
if (this_parm->category != production_category)
abort ();
this_parm_var = VARIABLE (this_parm);
if (!this_parm_var)
abort ();
if (this_parm_var->category != production_category)
abort ();
this_parms = my_malloc (sizeof (struct prod_token_parm_item));
if (!th
Re: Reloading Problems and Memory Addressing
On Monday 10 April 2006 19:48, you wrote:
> Can it at least add (small) immediates to registers?
Nope, sry. The only instructions that take other arguments than registers are
the aforementioned LDL/LDH (load low/high), branch instructions (they take a
memory address) and four bit operations which can mask, invert, set or delete
a bit in a register.
> IIRC, the PDP-11 is famous for accepting complex addresses, i.e. quite the
> opposite of your target machine, which is so simple I would suggest you
> write it from scratch. Does it need to be more than
>
Yes, you're right. When I started writing this backend I didn't have much
experience with it. I took the smallest backend I could find and tried to
adjust it to me needs. The number of macros in the internals docs was a bit
overwhelming at first and GCC kept segfaulting on me - something I'm
definately not used to from GCC. So, I was happy when I had something working
to start with. But now I think it would have been cleaner to start from
scratch.
> #define GO_IF_LEGITIMATE_ADDRESS(XMODE, X, LABEL) \
> if (REG_P (X)) \
> goto LABEL;
I tried that out today. I wasn't sure about the exact contexts in which this
macro is used. It seems to work fine, though.
> Try to add -fdump-rtl-greg or -fdump-rtl-greg-details when compiling
> __muldi3(). This will generate a libgcc2.c.*.greg file which will say
> exactly which reloads insn 260 has and which one is failing.
I will try that ASAP. But I'm now having problems with GCC (gcc-cross, for the
target machine) segfaulting again:
$ gcc function1.c
[...]
function1.c: In function 'main':
function1.c:10: internal compiler error: Segmentation fault
(gdb) bt
#0 0x0829028f in htab_find_slot (htab=0x5b52202c, element=0xbf805284,
insert=INSERT) at ../../gcc-4.0.2/libiberty/hashtab.c:707
#1 0x08215dc4 in cgraph_node (decl=0xb7d1b2f4)
at ../../gcc-4.0.2/gcc/cgraph.c:181
#2 0x082163b8 in cgraph_rtl_info (decl=0xb7d1b2f4)
at ../../gcc-4.0.2/gcc/cgraph.c:526
#3 0x0820e937 in rest_of_clean_state () at ../../gcc-4.0.2/gcc/passes.c:1477
#4 0x0809fbed in execute_pass_list (pass=0x82ede20)
at ../../gcc-4.0.2/gcc/tree-optimize.c:526
#5 0x0809fe53 in tree_rest_of_compilation (fndecl=0xb7d1b2f4)
at ../../gcc-4.0.2/gcc/tree-optimize.c:661
#6 0x0805a816 in c_expand_body (fndecl=0xb7d1b2f4)
at ../../gcc-4.0.2/gcc/c-decl.c:6611
#7 0x08217c65 in cgraph_expand_function (node=0xb7d1b57c)
at ../../gcc-4.0.2/gcc/cgraphunit.c:835
#8 0x08217d55 in cgraph_assemble_pending_functions ()
at ../../gcc-4.0.2/gcc/cgraphunit.c:307
#9 0x082183f5 in cgraph_finalize_function (decl=0xb7d1b2f4, nested=0 '\0')
at ../../gcc-4.0.2/gcc/cgraphunit.c:399
#10 0x0805abde in finish_function () at ../../gcc-4.0.2/gcc/c-decl.c:6580
#11 0x0804eb8e in yyparse () at c-parse.y:401
#12 0x0804f87b in c_parse_file () at c-parse.y:2936
#13 0x08081b0a in c_common_parse_file (set_yydebug=0)
at ../../gcc-4.0.2/gcc/c-opts.c:1102
#14 0x081f62c0 in toplev_main (argc=3212857988, argv=0xbf805e34)
at ../../gcc-4.0.2/gcc/toplev.c:1010
#15 0xb7dbaed0 in __libc_start_main () from /lib/tls/libc.so.6
#16 0x08049b71 in _start () at ../sysdeps/i386/elf/start.S:119
This is function1.c:
---
1: int foo (short i) {
2: i = 100;
3: return i+50;
4: }
5:
6: int main() {
7: int j = foo(10);
8: j += 25;
9: return j;
10: }
---
>
> 1) Does BP really have to be fixed? You are sufficiently desparate for
> registers than you'll not fix BP unless the hardware itself mandates this.
I thought it needs to be fixed if I want to set it aside as the frame pointer.
I removed it from the fixed registers and recompiled, but I haven't had a
closer look at the generated code yet. Can I do the same thing with SP?
>
> 2) GCC generally doesn't handle multi-word registers well. Even if you ask
> for a subreg, it will either load it all into registers or nothing at all.
> Richard Henderson posted a "multi-word subreg lowering" patch a while ago,
> which might help. See
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00554.html>. The patch
> needs to be updated to work on current mainline, though.
>
> 3) Reload sometimes fritters away registers. DJ Delorie recently submitted
> a patch to allow chaining of reloads, which reduces the number of registers
> needed in some cases. This will only help you if you upgrade your code base
> to mainline, though.
>
> If you can, develop against mainline rather than an old version of GCC.
I will move to mainline and see if it helps.
Thank you for your time and suggestions!
Cheers,
Frank
