Re: Memory leaks in compiler

2008-01-15 Thread Sebastian Pop
Hi, When a loop is vectorized, some statements are removed from the basic blocks, but the vectorizer information attached to these BBs is never freed. This is because the attached information is freed by walking the statements of the basic blocks: see tree-vectorizer.c:1750, but the transformed c

Re: Memory leaks in compiler

2008-01-15 Thread Sebastian Pop
Hi, one more leak, this time in alias analysis that initializes an obstak without freeing it. This is with the testcase of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821 valgrind --leak-check=full cc1 -O2 pr23821.c ==16661== 9,244 bytes in 68 blocks are definitely lost in loss record 2 of 5

Re: Memory leaks in compiler

2008-01-15 Thread Jerry DeLisle
Kaveh R. GHAZI wrote: On Fri, 11 Jan 2008, Vincent Lefevre wrote: ==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149) ==14240==by 0xB2F778: __gmp_default_allocate (in /mnt/sdb2/obj43/gcc/f951) ==14240==by 0x4C2B62D: mpfr_init2 (init2.c:53) ==14240==by 0x4C34424: mpfr_cache (

Re: Memory leaks in compiler

2008-01-15 Thread Kaveh R. GHAZI
On Fri, 11 Jan 2008, Vincent Lefevre wrote: > > ==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149) > > ==14240==by 0xB2F778: __gmp_default_allocate (in > > /mnt/sdb2/obj43/gcc/f951) > > ==14240==by 0x4C2B62D: mpfr_init2 (init2.c:53) > > ==14240==by 0x4C34424: mpfr_cache (cach

Segmented Register file Implementation

2008-01-15 Thread Balaji V. Iyer
Hello Everyone, I am currently working on dividing the register file into two different processing element. In the first processing element (PE) I want to have certain operations (add, sub, mult, div, branch, jumps..etc) in first PE and loads and stores should be in the 2nd Processing Eleme

Re: Rant and proposal about bitfield semantics in our IL and the C/C++ Frontend

2008-01-15 Thread Joseph S. Myers
On Tue, 15 Jan 2008, Michael Matz wrote: > Doing arithmetic on small bit-fields on the (larger) promoted type, but > doing them on large bit-fields on the exact width creates an asymmetry. It's the same as arithmetic on unsigned short actually being done on the promoted type (signed int), whi

Re: Rant and proposal about bitfield semantics in our IL and the C/C++ Frontend

2008-01-15 Thread Michael Matz
Hi, On Tue, 15 Jan 2008, Joseph S. Myers wrote: > On Mon, 14 Jan 2008, Richard Guenther wrote: > > > Can you clarify on the resulting promotions? As I remember the > > standard defines promotions based on the representable values, so > > long : 15 gets promoted to int, but long : 33 doesn't get

Re: jc1 out of memory error gcc 4.2.2 Linux 64-bit OS

2008-01-15 Thread Andrew Haley
Harpal Grover writes: > On Jan 14, 2008 5:09 AM, Andrew Haley <[EMAIL PROTECTED]> wrote: > > > > Harpal Grover writes: > > > Hello all, > > > > > > I downloaded and built gcc 4.2.2 on my linux box. I have also used the > > > sources to build a cross compiler using Ranjit's Matthews guide

Re: Rant and proposal about bitfield semantics in our IL and the C/C++ Frontend

2008-01-15 Thread Richard Guenther
On Tue, 15 Jan 2008, Joseph S. Myers wrote: > On Mon, 14 Jan 2008, Richard Guenther wrote: > > > Can you clarify on the resulting promotions? As I remember the > > standard defines promotions based on the representable values, so > > long : 15 gets promoted to int, but long : 33 doesn't get prom