H8SX: Bit instructions for review
Hi, H8SX target supports generation of bit instructions in memory addressing mode. However, these instructions are not getting generated and the bits in memory are operated using other instructions which consume more memory. The attached patch "h8sx.patch" generates these bit instructions and hence generates optimized code. We are aware that currently GCC is in stage-3. However, this patch is just for review so that it can be modified according to the review comments. The modified patch will then be posted to the gcc-patches mailing list once it returns to stage-1. Regards, Naveen.H.S. KPIT Cummins Infosystems Ltd, Pune ( INDIA ) www.kpitgnutools.com h8sx.patch Description: h8sx.patch
GNU Hurd changes vs. GCC: ``regression fixes and docs only''
Hello! We, the GNU Hurd people, would like to get GCC in a compilable/usable shape for us again, without needing to do the patching that was needed since the 4.2 release. I have already some weeks ago sent the needed patches to the gcc-patches mailing list, where they have been acked by Paolo and Matthias. Now that my GCC copyright assignment papers are on file and my sourceware account has been enabled for accessing the GCC repository, I could in theory install the patches. However, as I read on the homepage, GCC trunk is currently in ``regression fixes and docs only'' mode. Asking on OFTC's #gcc channel, after having stated that ``changes that are entirely port specific generally have some leeway; that is, if the change can only affect the Hurd target, then the Hurd maintainer may approve fixes for serious bugs even in regression-only mode'', Ian told me to raise this topic on the gcc list, as the ``problem'' is that currently no maintainer for the Hurdy bits is listed in MAINTAINERS. Being one of GNU Hurd upstream, I'd offer to fill that position. Regards, Thomas signature.asc Description: Digital signature
Re: GNU Hurd changes vs. GCC: ``regression fixes and docs only''
Thomas Schwinge wrote: > Hello! > > We, the GNU Hurd people, would like to get GCC in a compilable/usable > shape for us again, without needing to do the patching that was needed > since the 4.2 release. I have already some weeks ago sent the needed > patches to the gcc-patches mailing list, where they have been acked by > Paolo and Matthias. > > Now that my GCC copyright assignment papers are on file and my sourceware > account has been enabled for accessing the GCC repository, I could in > theory install the patches. However, as I read on the homepage, GCC > trunk is currently in ``regression fixes and docs only'' mode. Asking on > OFTC's #gcc channel, after having stated that ``changes that are entirely > port specific generally have some leeway; that is, if the change can only > affect the Hurd target, then the Hurd maintainer may approve fixes for > serious bugs even in regression-only mode'' I'm a build system maintainer, so I can approve fixes for those bugs if they only touch the build system and the fixes are clearly specific to Hurd. Global reviewers can do the same with the other fixes. Paolo
Re: GNU Hurd changes vs. GCC: ``regression fixes and docs only''
On Thu, Nov 6, 2008 at 8:57 AM, Thomas Schwinge <[EMAIL PROTECTED]> wrote: > Being one of GNU Hurd upstream, I'd offer to fill that position. I have forwarded this nomination to the GCC Steering Committee. David
Re: IRA accumulated costs
Vladimir Makarov wrote: Hi, Richard. Returning to accurate cost accumulation issue you found recently. Here is the patch fixing it. You could try, if you want, how MIPS will behave with it. The patch also more accurately calculates ALLOCNO_CALL_FREQ which affects decision to spill allocno in assign_hard_reg if it is more profitable. 2008-10-01 Vladimir Makarov <[EMAIL PROTECTED]> * ira-int.h (ira_allocno): Add member updated_cover_class_cost. (ALLOCNO_UPDATED_COVER_CLASS_COST): New. (ira_fast_allocation): Remove the prototype. * ira-color.c (update_copy_costs, allocno_cost_compare_func, assign_hard_reg, calculate_allocno_spill_cost): Use updated costs. (color_pass): Modify the updated costs. (ira_color): Rename to color. Make it static. (ira_fast_allocation): Rename to fast_allocation. Make it static. (ira_color): New function. * ira-conflicts.c (process_regs_for_copy): Propagate hard reg cost change. * ira-lives.c (last_call_num, allocno_saved_at_call): New variables. (set_allocno_live, clear_allocno_live, mark_ref_live, mark_ref_dead): Invalidate corresponding element of allocno_saved_at_call. (process_bb_node_lives): Increment last_call_num. Setup allocno_saved_at_call. Don't increase ALLOCNO_CALL_FREQ if the allocno was already saved. (ira_create_allocno_live_ranges): Initiate last_call_num and allocno_saved_at_call. * ira-build.c (ira_create_allocno): Initiate ALLOCNO_UPDATED_COVER_CLASS_COST. (create_cap_allocno, propagate_allocno_info, remove_unnecessary_allocnos): Remove setting updated costs. (ira_flattening): Set up ALLOCNO_UPDATED_COVER_CLASS_COST. * ira.c (ira): Don't call ira_fast_allocation. * ira-costs.c (setup_allocno_cover_class_and_costs): Don't set up updated costs. This is fine. Sorry about the long delay. Jeff
[EMAIL PROTECTED]: Results for 4.4.0 20081106 (experimental) [trunk revision 141636] (GCC) testsuite on m32c-unknown-elf]
This new failure seems to have been caused by r141613: +2008-11-05 Martin Jambor <[EMAIL PROTECTED]> + + PR middle-end/37861 + * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Don't turn + pointer arithmetics into array_ref if the array is accessed + through an indirect_ref. + The m32c-elf target is notoriously picky about getting pointer math "right" (pointers are 24 bits, not 16 or 32), anyone fiddling with pointer/array addressing stuff should probably test it to see if it breaks anything. Martin, can you see if you can reproduce this, and verify whether your change broke it or not? Or if it's something in m32c that your change expects to be configured differently? Thanks, DJ --- Start of forwarded message --- Multilib: m32c-sim/-mcpu=m32c PASS-FAIL: gcc.c-torture/execute/20010209-1.c execution, -O2 PASS-FAIL: gcc.c-torture/execute/20010209-1.c execution, -O3 -fomit-frame-pointer PASS-FAIL: gcc.c-torture/execute/20010209-1.c execution, -O3 -fomit-frame-pointer -funroll-loops PASS-FAIL: gcc.c-torture/execute/20010209-1.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions PASS-FAIL: gcc.c-torture/execute/20010209-1.c execution, -O3 -g LAST_UPDATED: Thu Nov 6 07:03:35 UTC 2008 (revision 141636) Target is m32c-unknown-elf Host is i686-pc-linux-gnu
Re: H8SX: Bit instructions for review
Naveen H.S. wrote: Hi, H8SX target supports generation of bit instructions in memory addressing mode. However, these instructions are not getting generated and the bits in memory are operated using other instructions which consume more memory. The attached patch "h8sx.patch" generates these bit instructions and hence generates optimized code. We are aware that currently GCC is in stage-3. However, this patch is just for review so that it can be modified according to the review comments. The modified patch will then be posted to the gcc-patches mailing list once it returns to stage-1. Don't forget to include the ChangeLog. Most of the patch looks OK for when we return to stage1 -- the only hunks I don't understand are the two peepholes. I'm having trouble seeing how they can possibly be right. It appears like the peepholes reverse the order of the branch and bit operation, thus causing the branch to be based on the output of the bit op rather than whatever was in cc0 from some previous operation. Can you explain why those two peepholes are correct, as written? Additionally, we'd prefer to use define_peephole2 rather than define_peephole whenever possible, if you could make that change as well it would be greatly appreciated. Jeff
gcc-4.3-20081106 is now available
Snapshot gcc-4.3-20081106 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20081106/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 141657 You'll find: gcc-4.3-20081106.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20081106.tar.bz2 C front end and core compiler gcc-ada-4.3-20081106.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20081106.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20081106.tar.bz2 C++ front end and runtime gcc-java-4.3-20081106.tar.bz2 Java front end and runtime gcc-objc-4.3-20081106.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20081106.tar.bz2The GCC testsuite Diffs from 4.3-20081030 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
Re: [help-texinfo] Re: small font in gcc online docs
You are expecting that the CSS large/small/x-small/etc match those of TeX. No, that is not the expectation. (It would be impossible, anyway. All these things are dynamically changeable in TeX.) The expectation is that firefox not reduce the size used when font-size:smaller is specified to something so small as to be nearly unreadable. Which is what is happening now. As you can see, for a medium font of 12 or 13 (which is the default size in Firefox), the small font is 10. Wow. That is quite the reduction, especially at screen resolutions. https://bugzilla.mozilla.org/show_bug.cgi?id=187256 Thanks. I hope Jonathan will follow up to that bug with his screenshot, etc., and that there is some hope of an eventual fix. Best, Karl
