Re: IRA conflict graph & alternative selection

Ian Lance Taylor wrote: Jeff Law writes: Ian Lance Taylor wrote: Jeff Law writes: No, that makes no sense. What I'm suggesting is that we fix the stack offsets of all local variables before register allocation, based on a conservative assessment of how many registers wil

Re: IRA conflict graph & alternative selection

Ian Lance Taylor wrote: Not a conservative guess at pseudo registers, a conservative guess at hard registers. I'm sorry, but I think I'm done with this thread. I'm just repeating myself, and people are critiquing things which I am not saying. FWIW, I'm not trying to be dense -- I respect and

RE: libiberty testsuite builds with wrong compiler

The same issue in the libiberty testsuite run can be seen with the Apple regress server log at http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip. If you search for test-demangle, you will find... + make -j2 -k check autogen -T /Users/regress/tbox/svn-gcc/fixincludes/check.tpl /Users/re

libiberty testsuite builds with wrong compiler

thing to be done for `check'. make[2]: Nothing to be done for `check'. gcc -DHAVE_CONFIG_H -g -O2 -I.. -I../../../gcc-4.4-20090221/libiberty/testsuite/../../include -o test-demangle \ ../../../gcc-4.4-20090221/libiberty/testsuite/test-demangle.c ../libiberty.a This

Re: IRA conflict graph & alternative selection

Jeff Law writes: > Ian Lance Taylor wrote: >> Jeff Law writes: >> >> No, that makes no sense. What I'm suggesting is that we fix the stack offsets of all local variables before register allocation, based on a conservative assessment of how many registers will be saved on the >

virtual destructors and operator delete

Hi, I have an auto-duration only class X in C++0x: class X { void* operator new(std::size_t) = delete; void operator delete(void*) = delete; public: virtual ~X() {} }; But GCC 4.4 fails to compile it: main.cpp: In destructor 'virtual X::~X()': main.cpp:414

Re: Stop daily bumps on autovect-branch?

On Sat, Feb 21, 2009 at 1:30 PM, Joseph S. Myers wrote: > On Sat, 21 Feb 2009, Steven Bosscher wrote: > >> Hi, >> >> No changes were checked in on the autovect-branch in the last ~15 >> months, but the branch still gets a daily bump on DATESTAMP. > > When I moved a lot of branches to the list of i

Re: Stop daily bumps on autovect-branch?

On Sat, 21 Feb 2009, Steven Bosscher wrote: > Hi, > > No changes were checked in on the autovect-branch in the last ~15 > months, but the branch still gets a daily bump on DATESTAMP. When I moved a lot of branches to the list of inactive branches in svn.html last July

Re: Stop daily bumps on autovect-branch?

On Sat, 21 Feb 2009, Richard Guenther wrote: > Huh, we do that? Yeah, feel free to adjust > maintainer_scripts/update_version_svn. I'm not sure Steven is on the gccadmin account, so I went ahead and committed the change below and also updated the script that is run by the crontab on gcc.gnu.org i

Re: Stop daily bumps on autovect-branch?

On Sat, Feb 21, 2009 at 11:20 AM, Steven Bosscher wrote: > Hi, > > No changes were checked in on the autovect-branch in the last ~15 > months, but the branch still gets a daily bump on DATESTAMP. > > Perhaps time to stop doing that? Huh, we do that? Yeah, feel free to adjust maintainer_scripts/u

Stop daily bumps on autovect-branch?

Hi, No changes were checked in on the autovect-branch in the last ~15 months, but the branch still gets a daily bump on DATESTAMP. Perhaps time to stop doing that? Gr. Steven

Re: targed.md: copy_to_mode_reg or force_reg?

in machine description expanders the functions copy_to_mode_reg and and force_reg from explow.c can be used to ensure that an operand lives in a register. But what function should be used? What are the differences? The only difference I can depict from the comment is that an operand returned by