Re: svn access on RHEL 4.0
On Fri, Jan 06, 2006 at 10:35:36PM -0600, Bradley Lucier wrote: > I'm having all kinds of trouble running svn on my RHEL 4.0 system. A > typical example of what's happening is: > > euler-62% svn cleanup > svn: XML parser failed in 'gcc/testsuite/gcc.dg/special' > > I first got that message when I tried contrib/gcc_update after doing > a svn checkout. Now I just get > > euler-63% contrib/gcc_update > Updating SVN tree > svn: Working copy '.' locked > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for > details) > Adjusting file timestamps > SVN update of full tree failed. > > > Does anyone have any helpful ideas of what to do? > I built/installed svn and related rpms from FC4 on RHEL 4. It works for me. H.J.
svn access on RHEL 4.0
I'm having all kinds of trouble running svn on my RHEL 4.0 system. A typical example of what's happening is: euler-62% svn cleanup svn: XML parser failed in 'gcc/testsuite/gcc.dg/special' I first got that message when I tried contrib/gcc_update after doing a svn checkout. Now I just get euler-63% contrib/gcc_update Updating SVN tree svn: Working copy '.' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) Adjusting file timestamps SVN update of full tree failed. Does anyone have any helpful ideas of what to do? Brad
Re: question about registers that are set on entry to a function.
Ian Lance Taylor wrote:
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
For complete accuracy, there are probably going to be some target
specific registers which need to be handled, unfortunately. For
example, on MIPS, with -mabicalls (which is the default on GNU/Linux),
$25 is live on function entry. It holds the address of the function,
and is used to initialize $28, which is PIC_OFFSET_TABLE_REGNUM. I
don't think there is any target independent way of getting at that
fact.
Is the right thing to do to define a target hook for this that
defaults to doing nothing and we only define it in those places where
necessary or should I add a few other macros to the ports as necessary
and just check to see if they are defined? I have noticed that there
are several macros that are only used on a single port.
I think the best approach would be a target hook. I guess you could
pass it the function decl and have it set bits in a bitmap or a
HARD_REG_SET. You might even want to do the whole thing in a target
hook, in which case the code you wrote would become the default
version of the hook (and would probably be called by non-default
versions). I don't have a strong feeling as to which approach would
be best.
Ian
Being the glutton for punishment, lets try this again.
I have one question about EH_USES on the ia-64 (the only place it is
used). The function
that implements this starts out with
int
ia64_eh_uses (int regno)
{
if (! reload_completed)
return 0;
This means that before register allocation, all of the uses of these
registers are hidden.
However, in the definition of REG_ALLOC_ORDER contains all of the
register that are defined in ia64_eh_uses after reload. It is at the
end of the order and there are a large number of registers but it seems
to me that if someone were to write a program that needed a large
boatload of registers, the register allocator might be tempted to use
these registers (unless there are no instruction patterns that use these
registers) and then the instruction exception unwinder would not work.
Is this a latent bug?
Asside from the concern from above and plumbing the target hook, how
does this look?
/* Record the (conservative) set of hard registers that are defined on
entry to the function. */
static void
df_record_entry_block_defs (struct dataflow * dflow)
{
unsigned int i;
bitmap_iterator bi;
rtx r;
struct df * df = dflow->df;
bitmap_clear (df->entry_block_defs);
if (! (df->flags & DF_HARD_REGS))
return;
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
{
if (FUNCTION_ARG_REGNO_P (i))
#ifdef INCOMING_REGNO
bitmap_set_bit (df->entry_block_defs, INCOMING_REGNO (i));
#else
bitmap_set_bit (df->entry_block_defs, i);
#endif
}
/* Once the prologue has been generated, all of these registers
should just show up in the first regular block. */
if (HAVE_prologue && epilogue_completed)
{
/* Defs for the callee saved registers are inserted so that the
pushes have some defining location. */
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
if ((call_used_regs[i] == 0) && (regs_ever_live[i]))
bitmap_set_bit (df->entry_block_defs, i);
}
else
{
if (REG_P (INCOMING_RETURN_ADDR_RTX))
bitmap_set_bit (df->entry_block_defs, REGNO (INCOMING_RETURN_ADDR_RTX));
/* If STATIC_CHAIN_INCOMING_REGNUM == STATIC_CHAIN_REGNUM
only STATIC_CHAIN_REGNUM is defined. If they are different,
we only care about the STATIC_CHAIN_INCOMING_REGNUM. */
#ifdef STATIC_CHAIN_INCOMING_REGNUM
bitmap_set_bit (df->entry_block_defs, STATIC_CHAIN_INCOMING_REGNUM);
#else
#ifdef STATIC_CHAIN_REGNUM
bitmap_set_bit (df->entry_block_defs, STATIC_CHAIN_REGNUM);
#endif
#endif
r = TARGET_STRUCT_VALUE_RTX (current_function_decl, true)
if (r && REG_P (r))
bitmap_set_bit (df->entry_block_defs, REGNO (r));
}
/* These registers are live everywhere. */
if (!reload_completed)
{
/* Any reference to any pseudo before reload is a potential
reference of the frame pointer. */
bitmap_set_bit (df->entry_block_defs, FRAME_POINTER_REGNUM);
#ifdef EH_USES
/* The ia-64, the only machine that uses this, does not define these
until after reload. */
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
if (EH_USES (i))
{
bitmap_set_bit (df->entry_block_defs, i);
}
#endif
#if FRAME_POINTER_REGNUM != ARG_POINTER_REGNUM
/* Pseudos with argument area equivalences may require
reloading via the argument pointer. */
if (fixed_regs[ARG_POINTER_REGNUM])
bitmap_set_bit (df->entry_block_defs, ARG_POINTER_REGNUM);
#endif
#ifdef PIC_OFFSET_TABLE_REGNUM
/* Any constant, or pseudo with constant equivalences, may
require reloading from memory using the pic register. */
if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM
&& fixed_regs[PIC_OFFSET_TABLE_REGNUM])
bitmap_set_bit (df->entry_block_defs,
RFC: adjusting spill preferences
In reload1.c:order_regs_for_reload() we calculate the cost of each register so that we can select which ones are used for spills. However, the calculations do not in any way account for the cost of each use of each register. For the m32c port, there are registers in the chip and registers in memory. The memory ones are more expensive. I've done all I can with constraint preferences, but it doesn't always work out because of the composite classes that reload needs (like A_REGS | MEM_REGS = A_MEM_REGS) so reload ends up using the expensive registers. For --mcpu=m32c, most on-chip registers need to be saved if they're used, but the memory ones don't, which further complicates the cost logic. What I'd like to do is add a target hook that's called at the end of order_regs_for_reload, passing either spill_cost itself or calling it once for each hard reg to obtain extra costs to add in (multiply by?). In my case, simply incrementing the cost by one is sufficient to prefer cpu regs over mem regs in simple tests. Suggestions? Comments? Objections? Is there some other existing cost metric I could use here?
Re: pr11135: make PIC register a pseudo
On Thu, Jan 05, 2006 at 01:40:05PM -0800, Ian Lance Taylor wrote: > > Regarding > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11135 > > > > How much effort would it take to fix this, at least for x86 (32-bit)? > > Not hard. See the MIPS backend, for example. Look at how it defines > PIC_OFFSET_TABLE_REGNUM and how it handles pic_offset_table_rtx. We already implement this. Indeed, the MIPS backend copied it from the x86 backend. The problem being that it doesn't take much effort at all to use the three call-clobbered registers and prevent the optimization. What they're looking for is, for functions that don't use the pic register, to not reserve the pic register so that it's available for computation. This is harder. In theory, ppc has some scheme for this, where they eliminate the pic register to itself. I've never really understood how that's supposed to work. r~
gcc-4.1-20060106 is now available
Snapshot gcc-4.1-20060106 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060106/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 109434 You'll find: gcc-4.1-20060106.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060106.tar.bz2 C front end and core compiler gcc-ada-4.1-20060106.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060106.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060106.tar.bz2 C++ front end and runtime gcc-java-4.1-20060106.tar.bz2 Java front end and runtime gcc-objc-4.1-20060106.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060106.tar.bz2The GCC testsuite Diffs from 4.1-20051230 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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 talk at LinuxWorld
There have been complaints that the GCC community doesn't do a good job of promoting itself, so in a presumptuous attempt to remedy that I'm giving a talk at LinuxWorld Conference and Expo in Boston in April on "Recent Developments in GCC". It doesn't require a paper, just a slide presentation. I'm planning to stick to high-level information: the scope of the product, an overview of the community, what's new in the last few releases and what might be coming in future releases. I expect to send questions to some of you about information I can't find elsewhere. I would welcome offers to review the slides, which must be ready by early February. Janis
Cleanups of TARGET_EXPR
Hello,
what exactly is the semantics of the cleanup for TARGET_EXPR?
Documentation says:
> Often, a @code{TARGET_EXPR} occurs on the right-hand side of an
> assignment, or as the second operand to a comma-expression which is
> itself the right-hand side of an assignment, etc. In this case, we say
> that the @code{TARGET_EXPR} is ``normal''; otherwise, we say it is
> ``orphaned''.
...
> If this expression is orphaned, then this expression must be executed
> when the statement containing this expression is complete.
What does "etc." in the definition of ``normal'' mean? Is say target_expr in
a = b ? TARGET_EXPR : something;
orphaned? If TARGET_EXPR is not orphaned, is it allowed to run its cleanup?
Zdenek
Re: Do the current gcc 3.4 and glibc 2.3 in CVS work on ia64?
On Fri, Jan 06, 2006 at 10:08:29AM -0800, H. J. Lu wrote: > With the current gcc 3.4 and glibc 2.3 in CVS, I got > > [EMAIL PROTECTED] glibc-2.3-import-3.4]$ gdb > ./build-ia64-linux/elf/ld-linux-ia64.so.2GNU gdb Red Hat Linux > (6.3.0.0-1.62rh) > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "ia64-redhat-linux-gnu"...Using host > libthread_db library "/lib/tls/libthread_db.so.1". > > (gdb) r > Starting program: > /export/build/gnu/glibc-2.3-import-3.4/build-ia64-linux/elf/ld-linux-ia64.so.2 > > Program received signal SIGSEGV, Segmentation fault. > 0x20002f91 in _dl_start (arg=0x6fff98a0) at rtld.c:260 > 260 HP_TIMING_DIFF_INIT (); > (gdb) > It looks like a binutils issue. I am investigating it now. H.J.
Do the current gcc 3.4 and glibc 2.3 in CVS work on ia64?
With the current gcc 3.4 and glibc 2.3 in CVS, I got [EMAIL PROTECTED] glibc-2.3-import-3.4]$ gdb ./build-ia64-linux/elf/ld-linux-ia64.so.2GNU gdb Red Hat Linux (6.3.0.0-1.62rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "ia64-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r Starting program: /export/build/gnu/glibc-2.3-import-3.4/build-ia64-linux/elf/ld-linux-ia64.so.2 Program received signal SIGSEGV, Segmentation fault. 0x20002f91 in _dl_start (arg=0x6fff98a0) at rtld.c:260 260 HP_TIMING_DIFF_INIT (); (gdb) H.J.
