Re: question about the ddg construction
On Thu, Jul 3, 2008 at 11:27 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote: > On Fri, Jul 4, 2008 at 1:25 AM, Tianwei <[EMAIL PROTECTED]> wrote: >> it won't query the aliaser for more precise information, maybe the >> code is a little older. > > Not at all, the DDG file is for the SMS pass which is relatively new. > One of the problems is that you can't really compute a dependence > distance on RTL, so for memory the DDG is just very conservative. > > You're not telling anything new, you know ;-) You probably want to > read http://gcc.gnu.org/wiki/SwingModuloScheduling too, Steven, thanks so much. that's really helpful. > > Gr. > Steven > -- Sheng, Tianwei Inst. of High Performance Computing Dept. of Computer Sci. & Tech. Tsinghua Univ.
Re: [whopr] Design/implementation alternatives for the driver and WPA
> I've updated the WHOPR Driver wiki page with our latest thoughts on > the plug-in interface: > > http://gcc.gnu.org/wiki/whopr/driver Very nice! Just one comment: On the "claim file", can you also pass the "file" size in the case it is inside an archive? > -cary > Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
mklibs on mips broken by gcc-4.3.x
I've been using the svn version of mklibs to reduce a cross compiled rootfs for mips or arm, and when I compile with gcc 4.2.x it all works fine. When I upgraded my toolchain to gcc 4.3.x then an arm rootfs still reduces with mklibs and runs correctly. However the mips build breaks mklibs with the following error: I: Using /home/steel/Projects/41/tuxbuilder/trunk/mipsel-unknown-linux-gnu/rootfs/lib/ld.so.1 as dynamic linker. I: library reduction pass 1 427 symbols, 423 unresolved /home/steel/Projects/41/tuxbuilder/trunk/mipsel-unknown-linux-gnu/cross/x86_64-cross-linux-gnu/bin/mklibs:496: DeprecationWarning: raising a string exception is deprecated raise "No library provides non-weak %s" % name Traceback (most recent call last): File "/home/steel/Projects/41/tuxbuilder/trunk/mipsel-unknown-linux-gnu/cross/x86_64-cross-linux-gnu/bin/mklibs", line 496, in raise "No library provides non-weak %s" % name No library provides non-weak [EMAIL PROTECTED] make: *** [/dev/shm/mipsel-unknown-linux-gnu/minirootfs] Error 1 __gnu_local_gp seems to be a mips specific symbol in gcc, which is apparently used to provide -mno-shared support to gcc. The implementation of this symbol is in gcc-4.x.x/gcc/config/mips/mips.c and the only thing which seems to have changed between gcc-4.2.4 and gcc-4.3.1 is the parameters passed to emit_insn, and the addition of a LOADGP_RTP option. Does anyone have any idea how this has broken, and how to work around / fix this in gcc or mklibs?
Re: mklibs on mips broken by gcc-4.3.x
On Fri, Jul 04, 2008 at 02:42:40PM +0100, Chris Steel wrote: > __gnu_local_gp seems to be a mips specific symbol in gcc, which is > apparently used to provide -mno-shared support to gcc. The > implementation of this symbol is in gcc-4.x.x/gcc/config/mips/mips.c > and the only thing which seems to have changed between gcc-4.2.4 and > gcc-4.3.1 is the parameters passed to emit_insn, and the addition of a > LOADGP_RTP option. Having run into this recently, I know what else changed: a configure-time check was added to use -mno-shared by default. Building with gcc 4.2 and -mno-shared will probably show the same problem. > Does anyone have any idea how this has broken, and how to work around > / fix this in gcc or mklibs? You'll have to make mklibs ignore this symbol; the linker defines it. -- Daniel Jacobowitz CodeSourcery
-Wmissing-field-initializers relaxation request
While trying to compile coreutils with -Wextra,
I noticed many warnings due to automatic variables
initialized with { 0, }.
As I understand it, since C90 the above will initialize
[all members of] the type to that used in static scope.
I.E. the following is valid:
mbstate_t m = { 0, };
int i = { 0, };
struct { int a; int b; } s = { 0, };
It would be great I think if gcc would relax this
warning in the specific case where { 0, } is specified.
I.E. with a trailing ',' as that would be clear indication
that one wants to init all elements to 0, and that
we haven't just forgotten some members.
thanks,
Pádraig.
Re: [whopr] Design/implementation alternatives for the driver and WPA
On Thu, Jul 03, 2008 at 09:48:11PM -0700, Ian Lance Taylor wrote: > * The linker does normally copy unrecognized sections with the > SHF_ALLOC bit clear to the output file. It doesn't allocate address > space for them, but it does copy them. I think this follows the ELF > ABI. I don't know of any generic way to direct the linker to not > copy sections to the output file. Didn't someone say on the gABI list recently that they had a bit for this? Ah, H. J. proposed it and Rod Evans from Sun said they already had an SHF_EXCLUDE: http://groups.google.com/group/generic-abi/browse_thread/thread/5cf669951cb2eef1 -- Daniel Jacobowitz CodeSourcery
gcc-4.4-20080704 is now available
Snapshot gcc-4.4-20080704 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080704/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 137492 You'll find: gcc-4.4-20080704.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080704.tar.bz2 C front end and core compiler gcc-ada-4.4-20080704.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080704.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080704.tar.bz2 C++ front end and runtime gcc-java-4.4-20080704.tar.bz2 Java front end and runtime gcc-objc-4.4-20080704.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080704.tar.bz2The GCC testsuite Diffs from 4.4-20080627 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
GCC 4.1 branch closed
The GCC 4.1 branch is now closed and should have no further commits. All open bugs at the 4.1.3 milestone, or marked as [4.1/4.2/4.3/4.4 Regression] or similar, have been updated accordingly. In going though these bugs, I noticed that many were marked as ASSIGNED, or as having patches, but had seen no recent activity. If a bug is assigned to you but you do not plan to do any further work on it (including if you fixed it on trunk but do not plan to backport the fix), please unassign yourself from the bug. If you have a patch for a bug that has not been reviewed, you need to make sure it has been posted to gcc-patches, then keep pinging it on gcc-patches every week or two until it is reviewed. Some bugs could be closed as fixed long ago even though the regression markers on them didn't indicate this; it may be useful for maintainers of parts of the compiler to go through relevant open bugs, confirming UNCONFIRMED ones and closing bugs that have been fixed on trunk (in the case of non-regressions) or on all open branches (in the case of regressions) and updating regression status for regressions fixed in some places but not everywhere. The 4.2 branch remains open with no plans for further releases. It should probably be closed around the time the 4.4 branch is created in the absence of a volunteer to maintain it and build releases beyond then. Previous 4.1 status report: http://gcc.gnu.org/ml/gcc/2007-05/msg00669.html -- Joseph S. Myers [EMAIL PROTECTED]
