On Jan 29, 2008 2:14 PM, Ira Rosen <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> [EMAIL PROTECTED] wrote on 16/01/2008 15:20:00:
>
> > > When a loop is vectorized, some statements are removed from the basic
> > > blocks, but the vectorizer information attached to these BBs is never
> > > freed.
> >
> > Se
(I am resending this, since some of the addresses got corrupted. My
apologies.)
Hi,
[EMAIL PROTECTED] wrote on 16/01/2008 15:20:00:
> > When a loop is vectorized, some statements are removed from the basic
> > blocks, but the vectorizer information attached to these BBs is never
> > freed.
>
>
(I am resending this, since some of the addresses got corrupted. My
apologies.)
Hi,
[EMAIL PROTECTED] wrote on 16/01/2008 15:20:00:
> > When a loop is vectorized, some statements are removed from the basic
> > blocks, but the vectorizer information attached to these BBs is never
> > freed.
>
>
Hi,
[EMAIL PROTECTED] wrote on 16/01/2008 15:20:00:
> > When a loop is vectorized, some statements are removed from the basic
> > blocks, but the vectorizer information attached to these BBs is never
> > freed.
>
> Sebastian, thanks for bringing this to our attention. I'll look into
this.
> I ho
On 18 January 2008 08:33, Gunther Nikl wrote:
> Kai Henningsen wrote:
>> On Thu, Jan 17, 2008 at 02:46:12PM -, Dave Korn wrote:
>>> On 16 January 2008 22:09, Diego Novillo wrote:
>>>
On 1/16/08 4:16 PM, Andrew Haley wrote:
> Because it's not a bug? You're changing the code to
Kai Henningsen wrote:
> On Thu, Jan 17, 2008 at 02:46:12PM -, Dave Korn wrote:
>> On 16 January 2008 22:09, Diego Novillo wrote:
>>
>>> On 1/16/08 4:16 PM, Andrew Haley wrote:
>>>
Because it's not a bug? You're changing the code to silence a false
negative, which this is what we here
On Thu, Jan 17, 2008 at 02:46:12PM -, Dave Korn wrote:
> On 16 January 2008 22:09, Diego Novillo wrote:
>
> > On 1/16/08 4:16 PM, Andrew Haley wrote:
> >
> >> Because it's not a bug? You're changing the code to silence a false
> >> negative, which this is what we here in England call "puttin
On Thu, Jan 17, 2008 at 11:08:25AM -0500, Ross Ridge wrote:
> Diego Novillo wrote:
> >I agree. Freeing memory right before we exit is a waste of time.
>
> Dave Korn writes:
> > So, no gcc without an MMU and virtual memory platform ever again?
> >Shame, it used to run on Amigas.
>
> I don't know
On Thu, Jan 17, 2008 at 11:08:25AM -0500, Ross Ridge wrote:
> Diego Novillo wrote:
> >I agree. Freeing memory right before we exit is a waste of time.
>
> Dave Korn writes:
> > So, no gcc without an MMU and virtual memory platform ever again?
> >Shame, it used to run on Amigas.
>
> I don't know
Diego Novillo wrote:
>I agree. Freeing memory right before we exit is a waste of time.
Dave Korn writes:
> So, no gcc without an MMU and virtual memory platform ever again?
>Shame, it used to run on Amigas.
I don't know if GCC ever freed all of its memory before exiting.
An operating system does
> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
Dave> So, no gcc without an MMU and virtual memory platform ever
Dave> again? Shame, it used to run on Amigas.
If you are serious about doing a port like this, then I will recant
and support not only this patch, but all the other ones you wil
On 16 January 2008 22:09, Diego Novillo wrote:
> On 1/16/08 4:16 PM, Andrew Haley wrote:
>
>> Because it's not a bug? You're changing the code to silence a false
>> negative, which this is what we here in England call "putting the cart
>> before the horse." If we clean up all the memory regions
On Wed, 16 Jan 2008, Tom Tromey wrote:
Kaveh> A valgrind suppression only silences the error for valgrind. What if
Kaveh> someone uses another memory checking tool? Better to fix it for real
Kaveh> IMHO.
Add suppressions for all of them. Any decent memory checker has to
account for the reali
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
> For what is to save developer time, which is way more valuable than cpu
> time.
If you are the only person running the compiler, then developer time
is far more valuable than CPU time. But tens of thousands of people
run the compiler, and they run i
On 1/16/08 4:16 PM, Andrew Haley wrote:
Because it's not a bug? You're changing the code to silence a false
negative, which this is what we here in England call "putting the cart
before the horse." If we clean up all the memory regions on closedown
we'll be wasting CPU time. And for what?
I
On Wed, 16 Jan 2008, Andrew Haley wrote:
> Kaveh R. Ghazi writes:
> > A valgrind suppression only silences the error for valgrind. What if
> > someone uses another memory checking tool? Better to fix it for real IMHO.
>
> Because it's not a bug? You're changing the code to silence a false
> n
From: "Tom Tromey" <[EMAIL PROTECTED]>
"Kaveh" == Kaveh R Ghazi <[EMAIL PROTECTED]> writes:
Kaveh> A valgrind suppression only silences the error for valgrind. What
if
Kaveh> someone uses another memory checking tool? Better to fix it for
real
Kaveh> IMHO.
Add suppressions for all of the
> "Kaveh" == Kaveh R Ghazi <[EMAIL PROTECTED]> writes:
Kaveh> A valgrind suppression only silences the error for valgrind. What if
Kaveh> someone uses another memory checking tool? Better to fix it for real
Kaveh> IMHO.
Add suppressions for all of them. Any decent memory checker has to
acc
Kaveh R. Ghazi writes:
> From: "Tom Tromey" <[EMAIL PROTECTED]>
>
> >> "Kaveh" == Kaveh R GHAZI <[EMAIL PROTECTED]> writes:
> >
> > Kaveh> + mpfr_free_cache ();
> >
> > Why not just add a valgrind suppression for this?
> > There's little point in freeing things just before exit.
> >
From: "Tom Tromey" <[EMAIL PROTECTED]>
"Kaveh" == Kaveh R GHAZI <[EMAIL PROTECTED]> writes:
Kaveh> + mpfr_free_cache ();
Why not just add a valgrind suppression for this?
There's little point in freeing things just before exit.
Tom
A valgrind suppression only silences the error for valgrin
> "Kaveh" == Kaveh R GHAZI <[EMAIL PROTECTED]> writes:
Kaveh> + mpfr_free_cache ();
Why not just add a valgrind suppression for this?
There's little point in freeing things just before exit.
Tom
> 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 transfor
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
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
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 (
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
Bernhard Fischer wrote:
On Fri, Jan 11, 2008 at 11:30:12AM -0800, Jerry DeLisle wrote:
With the Fortran test case I am using for PR34722. I did a valgrind check
with the following command:
valgrind --leak-check=full f951 inquire_12.f90
The possible problem in mpfr has been around a while.
T
On Fri, Jan 11, 2008 at 11:30:12AM -0800, Jerry DeLisle wrote:
> With the Fortran test case I am using for PR34722. I did a valgrind check
> with the following command:
>
> valgrind --leak-check=full f951 inquire_12.f90
>
> The possible problem in mpfr has been around a while.
>
> The other two p
On 2008-01-11 11:30:12 -0800, Jerry DeLisle wrote:
> With the Fortran test case I am using for PR34722. I did a valgrind
> check with the following command:
>
> valgrind --leak-check=full f951 inquire_12.f90
>
> The possible problem in mpfr has been around a while.
[...]
> I get the following:
>
Jerry DeLisle wrote:
With the Fortran test case I am using for PR34722. I did a valgrind
check with the following command:
valgrind --leak-check=full f951 inquire_12.f90
Here is a reduced test case. I will submit a PR. It has nothing to do with my
iostat patch for pr34722.
program gamsana
With the Fortran test case I am using for PR34722. I did a valgrind check with
the following command:
valgrind --leak-check=full f951 inquire_12.f90
The possible problem in mpfr has been around a while.
The other two problems look like middle-end or back-end problems. Does this
warrant a PR
31 matches
Mail list logo
