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
Carlos O'Donell <[EMAIL PROTECTED]> writes:
> Why is 16-bit int alignment the default for m68k in gcc?
>
> Which ABIs influenced this decision?
The original ABI was defined by Sun PCC. Note that the SysV ABI
actually uses natural alignment for all types, but that came only much
later.
You can f
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
Andreas, Jeff,
The documentation for `-malign-int' on m68k hints that 16-bit int
alignment was the prominent alignment chosen by m68k ABI's of the era.
Why is 16-bit int alignment the default for m68k in gcc?
Which ABIs influenced this decision?
Should Coldfire targets default to 16 or 32-bit
Snapshot gcc-4.2-20080116 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080116/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
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
On Wed, 16 Jan 2008, Dorit Nuzman wrote:
> >
> > From the last GCC Summit we learned about (Fortran) Frontend Based
> > Optimizations from Toon and it was suggested to tackle one issue by
> > promoting arrays to a first-class middle-end type. Discussion with
> > Sebastian also reveals that this m
> "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
Sergei Poselenov writes:
> Hello Andrew,
>
> > Now, I sympathize that in your particular case you have a code size
> > regression. This happens: when we do optimization in gcc, some code
> > bases will lose out. All that we can promise is that we try not to
> > make it worse for most users
Hello Andrew,
Now, I sympathize that in your particular case you have a code size
regression. This happens: when we do optimization in gcc, some code
bases will lose out. All that we can promise is that we try not to
make it worse for most users.
What we can do is compare your code that has g
Sergei Poselenov writes:
> Hello,
>
> I've just noted an error in my calculations: not 40%, but 10%
> regression (used gdb to do the calculations and forgot to convert
> inputs to float). Sorry.
>
> But the problem still persists for me - I'm building an embedded
> firmware (U-Boot) and i
>
> From the last GCC Summit we learned about (Fortran) Frontend Based
> Optimizations from Toon and it was suggested to tackle one issue by
> promoting arrays to a first-class middle-end type. Discussion with
> Sebastian also reveals that this makes sense to ease the analysis
> of the into-GRAPHI
Hello,
I've just noted an error in my calculations: not 40%, but 10%
regression (used gdb to do the calculations and forgot to convert
inputs to float). Sorry.
But the problem still persists for me - I'm building an embedded
firmware (U-Boot) and it doesn't fit into the reserved space
anymore.
> 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
Sergei Poselenov writes:
>
> No, all results are for the GCC project. "Mainline" here means the
> current development version of GCC. For it, the sum of the test code
> size is 3503061, vs. 3542052 for the gcc_4_0_0 branch. But again,
> this performance is achieved by the significant regressi
Sergei Poselenov writes:
> Hello all,
>
> I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
> size have increased significantly (about 40%!), comparing with
> old 4.0.0 when using the -Os option. Same code, same compile-
> and configuration-time options. Binutils are differ
> (2
> LLVM? From what I know llvm-gcc is an alternative for gcc. Are any
> parts of LLVM used in current GCC? None of what I know.
Sorry, I confused my mailing lists and thought you had asked on
the LLVM mailing list. This explains why I didn't understand
your questions :)
Sorry about the noise,
Du
Hi Duncan,
Duncan Sands wrote:
Hi,
I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
size have increased significantly (about 40%!), comparing with
old 4.0.0 when using the -Os option. Same code, same compile-
and configuration-time options. Binutils are differ
(2.16.1 vs 2.17.50),
Hi,
> I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
> size have increased significantly (about 40%!), comparing with
> old 4.0.0 when using the -Os option. Same code, same compile-
> and configuration-time options. Binutils are differ
> (2.16.1 vs 2.17.50), though.
what LLVM versi
Hello all,
I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
size have increased significantly (about 40%!), comparing with
old 4.0.0 when using the -Os option. Same code, same compile-
and configuration-time options. Binutils are differ
(2.16.1 vs 2.17.50), though.
I've looked at th
25 matches
Mail list logo
