powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
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 the CSiBE testing results for ppc-elf with -Os, comparing gcc_4_0_0 with mainline and found that the mainline actually optimizes better, at least for the CSiBE test environment. After some analysis I've came to the following results: Number of packages in the CSiBE test environment: 863 N of packages where mainline GCC optimizes better: 290 N of packages where mainline GCC optimizes worse: 436 And the regression in code size is up to 40%, like in my case. What I'm missing here? Apparently, just "-Os" is not enough to get the best size-optimized code? Currently, it builds as following: ppc-linux-gcc -g -Os -fPIC -ffixed-r14 -meabi -fno-strict-aliasing -D__KERNEL__ -DTEXT_BASE=0xfffc -I/work/psl/tmp/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/eldk-4.2-01-08/usr/bin/../lib/gcc/powerpc-linux/4.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 -ffixed-r29 -mstring -msoft-float -Wa,-m440 -mcpu=440 -DCONFIG_440=1 -Wall -Wstrict-prototypes -c -o interrupts.o interrupts.c What would you suggest? Thanks for any help, Sergei
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
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 version is old 4.0.0? Are you compiling C++ (I don't know what CSiBE is)? Are you using exception handling? > I've looked at the CSiBE testing results for ppc-elf with -Os, > comparing gcc_4_0_0 with mainline and found that the mainline > actually optimizes better, at least for the CSiBE test environment. > After some analysis I've came to the following results: > Number of packages in the CSiBE test environment: 863 > N of packages where mainline GCC optimizes better: 290 > N of packages where mainline GCC optimizes worse: 436 From these numbers it looks like llvm-gcc is better than mainline most of the time. However you say: "... found that the mainline actually optimizes better". Can you please clarify. Best wishes, Duncan.
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
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), though. what LLVM version is old 4.0.0? Are you compiling C++ (I don't know what CSiBE is)? Are you using exception handling? 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. CSiBE is the Code-Size Benchmark Environment, see http://www.inf.u-szeged.hu/csibe I've looked at the CSiBE testing results for ppc-elf with -Os, comparing gcc_4_0_0 with mainline and found that the mainline actually optimizes better, at least for the CSiBE test environment. After some analysis I've came to the following results: Number of packages in the CSiBE test environment: 863 N of packages where mainline GCC optimizes better: 290 N of packages where mainline GCC optimizes worse: 436 From these numbers it looks like llvm-gcc is better than mainline most of the time. However you say: "... found that the mainline actually optimizes better". Can you please clarify. 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 regression for the most of the test packages. Regards, Sergei Best wishes, Duncan.
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
> 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, Duncan.
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
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.16.1 vs 2.17.50), though. > > I've looked at the CSiBE testing results for ppc-elf with -Os, > comparing gcc_4_0_0 with mainline and found that the mainline > actually optimizes better, at least for the CSiBE test environment. > After some analysis I've came to the following results: > Number of packages in the CSiBE test environment: 863 > N of packages where mainline GCC optimizes better: 290 > N of packages where mainline GCC optimizes worse: 436 > > And the regression in code size is up to 40%, like in my case. 40% seems severe, but it may be an outlier. What is the average increase in code size, including the packages where it got better? > What I'm missing here? Apparently, just "-Os" is not enough to > get the best size-optimized code? Not necessarily. -Os is mostly [*] the same as -O2 but with optimizations that might reasonably be expected to cause code size increase disabled. You might find some better combination of options for your code base. Andrew. [*] Full disclosure: There are a few optimizations, such as code hoisting, that are specially used with -Os. There are also some passes with special tuning for -Os. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
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 regression for the > most of the test packages. Hold on, that's a 1.1% improvement in code size, not a regression. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Memory leaks in compiler
> 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 code does not contain all the stmts of the original > code. I can't find out a good solution for tracking these stmts, but > one solution could be to free the stmt_info when the stmts are removed > from a BB. Sebastian, thanks for bringing this to our attention. I'll look into this. I hope that removing stmts from a BB can be easily localized. -- Victor
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
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. Andrew Haley wrote: 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.16.1 vs 2.17.50), though. > > I've looked at the CSiBE testing results for ppc-elf with -Os, > comparing gcc_4_0_0 with mainline and found that the mainline > actually optimizes better, at least for the CSiBE test environment. > After some analysis I've came to the following results: > Number of packages in the CSiBE test environment: 863 > N of packages where mainline GCC optimizes better: 290 > N of packages where mainline GCC optimizes worse: 436 > > And the regression in code size is up to 40%, like in my case. 40% seems severe, but it may be an outlier. What is the average increase in code size, including the packages where it got better? Specifically, in my case the digits are as follows (as reported by 'size'): gcc 4.2.2: textdata bss dec hex filename 2696 601536429210c4 interrupts.o gcc 4.0.0: textdata bss dec hex filename 2424 8815364048 fd0 interrupts.o (about 10% regression) As for the CSiBE results - the average regression is 3%, including top 3 winners: 100% (32768 vs 16384 for "linux-2.4.23-pre3-testplatform - arch/testplatform/kernel/init_task") 35% (1440 vs 1064 for "teem-1.6.0-src - src/air/enum") 34% (1712 vs 1280 for "teem-1.6.0-src - src/nrrd/encodingHex") (See http://www.inf.u-szeged.hu/csibe/osingle.php?branchid=mainline&targetid=ppc-elf×tamp=2008-01-15%2012:00:00&flags=-Os&csibever=2.x.x&projectid=---%20all%20files%20---&finish_button=Finish for mainline results, and http://www.inf.u-szeged.hu/csibe/osingle.php?branchid=gcc_4_0_0_release&targetid=ppc-elf×tamp=2003-01-01%2012:00:00&flags=-Os&csibever=2.x.x&projectid=---%20all%20files%20---&finish_button=Finish for gcc_4_0_0_release results) For comparison bar chart see http://www.inf.u-szeged.hu/csibe/ocomp.php?branchid_a=gcc_4_0_0_release&branchid_b=mainline&targetid_a=ppc-elf&targetid_b=ppc-elf×tamp_a=2003-01-01%2012:00:00×tamp_b=2008-01-15%2012:00:00&flags_a=-Os&flags_b=-Os&csibever_a=2.x.x&csibever_b=2.x.x&dataview=Code%20size&viewmode=Bar%20chart&finish_button=Finish > What I'm missing here? Apparently, just "-Os" is not enough to > get the best size-optimized code? Not necessarily. -Os is mostly [*] the same as -O2 but with optimizations that might reasonably be expected to cause code size increase disabled. You might find some better combination of options for your code base. Understood. I raised the question in a hope that somebody already have a set of useful options for powerpc cross to try with -Os. Thanks, Sergei Andrew. [*] Full disclosure: There are a few optimizations, such as code hoisting, that are specially used with -Os. There are also some passes with special tuning for -Os.
Re: [RFC] Introduce middle-end expressions on arrays
>
> 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-GRAPHITE transformation by not dropping information that
> cannot be re-computed.
>
> ...
Maybe something like the infrastructure you propose could also fascilitate
supporting vectorization into "virtual vectors" (vectors whose size is
unknown)? (as raised in this thread:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00687.html - i.e. to
vectorizer w/o knowing any target specific info, including vector sizes).
(Or is there a different way to express such a thing?)
This would also let us split the vectorizer into a target-independent part,
that uses the vector size as a parameter, followed by a target dependent
part that materializes the vectors into actual vectors as supported by the
target (including alignment handling, etc). The target dependent part would
be invoked when the target machine is known at compile time. For cases when
you use dynamic/JIT compilation (e.g. targets like
http://gcc.gnu.org/projects/cli.html) the target dependent part would take
place during JIT compilation later on.
>
> Another point for the motivation is that vector constructs should
> survive till the point where GCC knows/uses information about the
> vector target machine with using the vectorizer (as part of the
> GRAPHITE framework) to create regular (optimized) scalar IL from
> the array operations.
>
(Just to clarify - when you say "using the vectorizer to create regular
scalar IL" from whole-array constructs, you mean a "scalar IL" that also
includes the kind of operations on vector types we have today, right?)
Until such time when the vectorizer is incorporated in GRAPHITE, the
vectorizer could already benefit from preserving whole-array operations (by
avoiding the introduction of redundant dependences/order-constraints).
However, the early lowering you require means that we can't keep the array
expressions around until vectorization in its current location. Is that a
strict restriction? Can this IL extension live longer?
thanks,
dorit
>
> So this is a proposal to make this happen, allow statements and
> expressions that operate on (multidimensional) arrays.
>
> The first and maybe most important issue is that temporaries required
> by either design issues of the IL or by optimizations are not going
> to be cheap. The second issue is the question of if (yes I'd say) and
> when (very early I'd say) we want to lower statements / expressions
> on arrays and generate loop constructs for them.
>
>
> On the first issue, how to represent array expressions in the IL we
> can take the pragmatic approach for now and merely try to make the
> expressions survive until they get picked up by GRAPHITE (or other
> to-be-invented special optimizers) but allow scalar optimizers to
> operate on scalar parts of the expressions. To avoid creating
> temporaries of array type, which the gimplifier in its current form
> cannot do for variable length types, we do not create full GIMPLE
> form of array expressions, but retain GENERIC expressions in RHS.
> With the very experimental prototype patch (that just was done to
> experiment with forms of the IL) we would for example end up with
>
> float a[16];
> float b[16];
> float c[16];
>
> tmp = 0.0;
> a.1 = &a;
> b.2 = &b;
> c.3 = &c;
> n.4 = n;
> D.1558 = (long unsigned int) n.4;
> D.1559 = D.1558 * 4;
> *a.1 = WITH_SIZE_EXPR <(*b.2 + *c.3) + tmp, D.1559>;
> D.1560 = a[0];
> return D.1560;
>
> for the whole array expression C source
>
> float test5 (int n)
> {
> float a[16];
> float b[16];
> float c[16];
> float tmp = 0.0;
> *(float (*)[n])&a = *(float (*)[n])&b + *(float (*)[n])&c + tmp;
> return a[0];
> }
>
> Ignore the WITH_SIZE_EXPR here, the point is that we have two
> operations and three operands on the rhs, two arrays, one scalar.
> CCP happily propagates 0.0 into the expression and if you do not
> run SRA (which ICEs) you survive until expand, which of course has
> no idea how to deal with this expression ;)
>
> So we think this approach is sound if these expressions do not survive
> for too long (that is, only until after out-of-GRAPHITE).
>
>
> A different approach would be to only allow whole arrays as gimple
> values and proceed with usual gimplification of expressions. To
> avoid to have to allocate memory for the array temporaries we could
> represent them as pointers to (not yet) allocated storage like
> for the above case
>
>float (* D.29)[n] = (float (*)[n])&a;
>float (* D.30)[n] = (float (*)[n])&b;
>float (* D.31)[n] = (float (*)[n])&c;
>float (* D.42)[n];
>D.42 = __builtin_vla_tmp_alloc (n * 4);
>*D.42 = *D.30 + *D.31;
>*D.29 = *D.42 + tmp;
>__builtin_vla_tmp_free (D.43);
>
> where we still wo
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
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 it doesn't fit into the reserved space > anymore. > > Andrew Haley wrote: > > 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.16.1 vs 2.17.50), though. > > > > > > I've looked at the CSiBE testing results for ppc-elf with -Os, > > > comparing gcc_4_0_0 with mainline and found that the mainline > > > actually optimizes better, at least for the CSiBE test environment. > > > After some analysis I've came to the following results: > > > Number of packages in the CSiBE test environment: 863 > > > N of packages where mainline GCC optimizes better: 290 > > > N of packages where mainline GCC optimizes worse: 436 > > > > > > And the regression in code size is up to 40%, like in my case. > > > > 40% seems severe, but it may be an outlier. What is the average > > increase in code size, including the packages where it got better? > > > > > Specifically, in my case the digits are as follows (as reported by > 'size'): > gcc 4.2.2: > textdata bss dec hex filename > 2696 601536429210c4 interrupts.o > > gcc 4.0.0: > textdata bss dec hex filename > 2424 8815364048 fd0 interrupts.o > > (about 10% regression) Sure, but this is a tiny sample. > As for the CSiBE results - the average regression is > 3%, including top 3 winners: > 100% (32768 vs 16384 for "linux-2.4.23-pre3-testplatform - > arch/testplatform/kernel/init_task") > 35% (1440 vs 1064 for "teem-1.6.0-src - src/air/enum") > 34% (1712 vs 1280 for "teem-1.6.0-src - src/nrrd/encodingHex") I've just re-read what you wrote, and noticed your comment above: "the mainline actually optimizes better, at least for the CSiBE test environment." Quite so: http://www.inf.u-szeged.hu/csibe/ocomp.php?branchid_a=gcc_4_0_0_release&branchid_b=mainline&targetid_a=arm-elf&targetid_b=arm-elf×tamp_a=2003-01-01%2012:00:00×tamp_b=2008-01-14%2012:00:00&flags_a=-Os&flags_b=-Os&csibever_a=2.x.x&csibever_b=2.x.x&dataview=Code%20size&viewmode=Summarized%20bar%20chart&finish_button=Finish So we're actually doing better now than we were in 4.0.0. 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 got much worse, and try to figure out why. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
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 got much worse, and try to figure out why. Would the generated asm listings be enough? Or should I send the preprocessed sources as well? Thanks a lot! Regards, Sergei Andrew.
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
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. > > > > What we can do is compare your code that has got much worse, and try > > to figure out why. > > > > Would the generated asm listings be enough? Or should I send > the preprocessed sources as well? Both. Rather than sending stuff, best to stick it on a web site if you can. Having said that, your example is tiny, so it's likely that it won't be very representative, and the less representative the code is the less likely a gcc maintainer will be interested. But at least we'll be able to see the difference. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Memory leaks in compiler
> "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
Re: [RFC] Introduce middle-end expressions on arrays
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 makes sense to ease the analysis > > of the into-GRAPHITE transformation by not dropping information that > > cannot be re-computed. > > > > ... > > Maybe something like the infrastructure you propose could also fascilitate > supporting vectorization into "virtual vectors" (vectors whose size is > unknown)? (as raised in this thread: > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00687.html - i.e. to > vectorizer w/o knowing any target specific info, including vector sizes). > (Or is there a different way to express such a thing?) > > This would also let us split the vectorizer into a target-independent part, > that uses the vector size as a parameter, followed by a target dependent > part that materializes the vectors into actual vectors as supported by the > target (including alignment handling, etc). The target dependent part would > be invoked when the target machine is known at compile time. For cases when > you use dynamic/JIT compilation (e.g. targets like > http://gcc.gnu.org/projects/cli.html) the target dependent part would take > place during JIT compilation later on. Hm, can't you just use arbitrary middle-end vector types now? You probably have to give them BLKmode (as no HW vector mode might exist for arbitrary sizes), but everything else would just work. The array types would be mainly introduced to allow arbitrary dimensional data types, which we do not allow in expressions currently. But yes, a one-dimensional array could then also be viewed as vector. I don't have a strong opinion on whether the real VECTOR_TYPEs should be constrained to ones mappable to a real machine mode or not (I guess we'll just experiment). > > Another point for the motivation is that vector constructs should > > survive till the point where GCC knows/uses information about the > > vector target machine with using the vectorizer (as part of the > > GRAPHITE framework) to create regular (optimized) scalar IL from > > the array operations. > > > > (Just to clarify - when you say "using the vectorizer to create regular > scalar IL" from whole-array constructs, you mean a "scalar IL" that also > includes the kind of operations on vector types we have today, right?) Right. That was for the time the vectorizer works on the GRAPHITE IL. > Until such time when the vectorizer is incorporated in GRAPHITE, the > vectorizer could already benefit from preserving whole-array operations (by > avoiding the introduction of redundant dependences/order-constraints). > However, the early lowering you require means that we can't keep the array > expressions around until vectorization in its current location. Is that a > strict restriction? Can this IL extension live longer? In principle the IL can live until expansion to RTL, but the usual scalar optimizers will not work on these parts, so the trade-off is either lowering early and have the scalar optimizers optimize or lowering later and depend on the lowering process to generate optimized code already. Again, we have to experiment with that. I also hope to have something ready to present at the Summit about this. Thanks, Richard.
Re: Memory leaks in compiler
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 valgrind. What if someone uses another memory checking tool? Better to fix it for real IMHO. --Kaveh -- Kaveh R. Ghazi
Re: Memory leaks in compiler
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. > > Tom > > 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 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? Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Memory leaks in compiler
> "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 account for the reality that many programs don't bother freeing memory before exit. Or, to put it another way, why add this free and not, say, something to free all the other memory allocated by gcc which is live at exit? I think there are a lot of instances of this. Tom
Re: Memory leaks in compiler
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 them. Any decent memory checker has to account for the reality that many programs don't bother freeing memory before exit. That a maintenance headache. Why fix problems in multiple places (checking tools) when you can fix it once and for all in a single place? Otherwise some guy using another tool has to scratch his head, spend time and wonder is this a real bug or not? I'd rather not waste time for the next volunteer who uses a different tool. Or, to put it another way, why add this free and not, say, something to free all the other memory allocated by gcc which is live at exit? I think there are a lot of instances of this. Tom I would free them all if they are easy to do. I.e. sometimes you don't have a clear handle on the memory at the point you know it's ready to be free'd or you're exitting. However this one is simple. --Kaveh -- Kaveh R. Ghazi
Re: Memory leaks in compiler
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 > 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? > Andrew. For what is to save developer time, which is way more valuable than cpu time. As I mentioned to Tom, someone using another memory checking tool will run into the same problem and he'll waste time reinventing the wheel. And someone on this list will have to remind him about this "known" problem. Even so if cpu time is a concern, I don't believe that it's a factor here. I challenge you to show that this free'ing of memory can be measured and shows up on a profile. Even on an *empty* file at -O0, I seriously double the mpfr_free_cache eats any cpu that you can measure, let alone measuring it on a serious module of any releavent size at higher optimization. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
gcc-4.2-20080116 is now available
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/gcc-4_2-branch revision 131580 You'll find: gcc-4.2-20080116.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080116.tar.bz2 C front end and core compiler gcc-ada-4.2-20080116.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080116.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080116.tar.bz2 C++ front end and runtime gcc-java-4.2-20080116.tar.bz2 Java front end and runtime gcc-objc-4.2-20080116.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080116.tar.bz2The GCC testsuite Diffs from 4.2-20080109 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
History of m68k ABI and `-malign-int'?
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 int alignment? Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716
Re: Memory leaks in compiler
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 agree. Freeing memory right before we exit is a waste of time. Diego.
Re: History of m68k ABI and `-malign-int'?
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 find much of the history in the change logs of gcc 1.42. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Memory leaks in compiler
"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 it many times. The CPU time adds up. This is a trivial example and it doesn't really matter. But, as a general rule, we should not free memory on compiler exit. One reasonable compromise would be to only free the memory if ENABLE_CHECKING is defined. Ian
Re: Memory leaks in compiler
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 reality that many programs don't bother freeing memory before exit. Valgrind (Memcheck) generally only complains about unfreed blocks for which there is no pointer in live data, ie. truly leaked ones. But it's not perfect, there are various ways it can be fooled. Nick
