Re: [RFC] Remove -frtl-abstract-sequences in 4.5

Diego Novillo wrote: On Mon, Nov 24, 2008 at 12:23, Mark Mitchell <[EMAIL PROTECTED]> wrote: David Edelsohn wrote: It currently is broken on many platforms. Why not remove it now? What is the purpose of keeping a pass that does not work correctly and developers cannot use? As

Re: Warning when compiling dwarf2out.c with -ftree-parallelize-loops=4

Hi, > As far as I get it, there is no real failure here. > Parloop, unaware of the array's upper bound, inserts the 'enough > iterations' condition (i>400-1), and thereby > makes the last iteration range from 400 upwards. > VRP now has a constant it can compare to the array's upper bound. > Cor

Re: GCC 3.4.6 on x86_64: __builtin_frame_address(1) of topmost frame doesn't return 0x0

__builtin_frame_address with non-zero arguments is not supported on most targets these days. It'll work on x86-64 if you also compile with -fno-omit-frame-pointer. That said, you almost certainly want to be using backtrace(3) instead. r~

Warning when compiling dwarf2out.c with -ftree-parallelize-loops=4

Hi, When enabling -ftree-parallelize-loops=4 , bootstrap fails: cc1: warnings being treated as errors ../../gcc/gcc/dwarf2out.c: In function âdwarf2out_frame_debugâ: ../../gcc/gcc/dwarf2out.c:2393: error: array subscript is above array bounds ../../gcc/gcc/dwarf2out.c:2394: error: array subscrip

Re: |new []| better not overflow and crash with g++

* Georgi Guninski: > once upon a time |calloc(BIG,BIG)| silently overflowed, now it is fixed. > > nowadays |new int[bignumber]| overflows as in: This is PR19351, first reported in 2002 (along with the calloc issue).

GCC 3.4.6 on x86_64: __builtin_frame_address(1) of topmost frame doesn't return 0x0

Hi, in binaries compiled with gcc 3.4.6 on an x86_64 machine, I get the following behaviour. I wrote a little testcase: int main(int argc, char **argv) { unsigned long addr; if ( (addr = (unsigned long)(__builtin_frame_address(0))) ) { printf ("0x%08lx\n", addr); if ( (addr = (uns

Re: Problem reading corefiles on ARM

Hi, I was reading the "Problem reading corefiles on ARM" thread at the gcc mailing list (from www-archive, I'm not subscribed) and the conclusions are incorrect: http://gcc.gnu.org/ml/gcc/2008-08/msg00075.html The problem in GCC noreturn attribute handling isn't how it optimizes calling

|new []| better not overflow and crash with g++

once upon a time |calloc(BIG,BIG)| silently overflowed, now it is fixed. nowadays |new int[bignumber]| overflows as in: [1] volatile size_t n; n= 4+((size_t)-1)/sizeof(int); int *ptr; cout << "n=" << n << endl; ptr=new int[n]; cout << "ptr=" << ptr << endl; cout << "ptr[n/2]=" << ptr[n/2] << endl;