Re: GCC Garbage Collection

Le Mon, Nov 13, 2006 at 06:47:40AM +, Brendon Costa écrivait/wrote: > Hi All, > >I think i am having trouble with the garbage collector deleting the > memory for tree nodes that i am still using. The wiki page http://gcc.gnu.org/wiki/Memory_management might help you I had a quick gl

Re: C++: Implement code transformation in parser or tree

Quoting Gabriel Dos Reis <[EMAIL PROTECTED]>: [EMAIL PROTECTED] writes: | > There is the discussion on callbacks. | | Are these discussions public? Most of them happened at the last C++ committee meetings in Berlin, Germany and Portland, Oregon). There must be some record on the EWG wiki, but

GCC Garbage Collection

Hi All, I think i am having trouble with the garbage collector deleting the memory for tree nodes that i am still using. In my code i gather all sorts of information from FUNCTION_DECL nodes as they pass through the gimplify_function_tree() function. I gather info about types and funct

Re: Reducing the size of C++ executables - eliminating malloc

> GCC 4.1.1 for PowerPC generates a 162K executable for a > minimal program "int main() { return 0; }". GCC 3.4.1 > generated a 7.2K executable. Mark Mitchell mentioned the > same problem for ARM and proposed a patch to remove the > reference to malloc in atexit > (http://sourceware.org/ml/newl

RE: How to create both -option-name-* and -option-name=* options?

On 11 November 2006 00:14, Brooks Moses wrote: > Dave Korn wrote: >> On 10 November 2006 21:18, Brooks Moses wrote: >> I think that for this one case we should just say that you have to supply >> both forms -ffixed-line-length-none and -ffixed-line-length=none. > > Which I would be glad to do,

RE: Abt long long support

On 10 November 2006 22:31, 'Rask Ingemann Lambertsen' wrote: > On Fri, Nov 10, 2006 at 07:11:34PM -, Dave Korn wrote: > >> No, surely you don't want to do that! You really need a movdi pattern - >> even more so if there are no natural DImode-sized registers, as gcse can >> get terribly con

Re: Abt long long support

First thanks very much for your thoughts If those two instructions appear for the first time in the .greg dump file, then they have been created by reload. Yes they appear for the first time in .greg dump file. > 1. What could be the reason for this behavior? I'm really shooting in the da

GCC 4.1.2 Status Report (2006-11-12)

I realize that it's been a long time since a GCC 4.1.x release. I'd like to put together a GCC 4.1.2 release in the relatively near future. (Then, there may or may not be a GCC 4.1.3 release at the same time as 4.2.0, depending on where it seems like we are at that point.) Since, in theory, the

Would this interest anyone?

I am no longer subscribed to this list so please be sure to include my email address in any replies. I have been working on a set of class templates. Currently my example is rather large and cumbersome. I get the same results using g++ 4.0.1 on the Mac and g++ 4.0.2 on AIX. The templates

Re: C++: Implement code transformation in parser or tree

[EMAIL PROTECTED] writes: | > There still are some discussions going on (it is not alsways feasable | > to reflect all the discussions), especially with respect to callback, | > default policy and the like. | > | [...] | | > There is the discussion on callbacks. | | Are these discussions public?

Re: C++: Implement code transformation in parser or tree

> There still are some discussions going on (it is not alsways feasable > to reflect all the discussions), especially with respect to callback, > default policy and the like. > [...] > There is the discussion on callbacks. Are these discussions public? Is there a way to get archives? Thanks, So

Re: Reducing the size of C++ executables - eliminating malloc

Daniel Jacobowitz wrote: > On Sun, Nov 12, 2006 at 05:11:39PM -0800, Mark Mitchell wrote: >> Daniel Jacobowitz wrote: >> >>> If you try what Michael's been saying, you'll notice that trivial >>> C++ files get the personality routine reference even if they don't >>> have anything with a destructor w

Re: Reducing the size of C++ executables - eliminating malloc

On Sun, Nov 12, 2006 at 05:11:39PM -0800, Mark Mitchell wrote: > Daniel Jacobowitz wrote: > > > If you try what Michael's been saying, you'll notice that trivial > > C++ files get the personality routine reference even if they don't > > have anything with a destructor which would need cleaning up.

Re: Reducing the size of C++ executables - eliminating malloc

On Mon, Nov 13, 2006 at 01:03:10AM +, Paul Brook wrote: > > C++ files get the personality routine reference even if they don't > > have anything with a destructor which would need cleaning up. We ought > > to be able to emit (somewhat smaller) unwind information which doesn't > > reference the

Re: C++: Implement code transformation in parser or tree

Mark Mitchell <[EMAIL PROTECTED]> writes: [...] | Also, it appears to me that there is something missing from N1958: there | is no discussion about what happens when you apply typeid to a lambda | function, or otherwise use it in a context that requires type_info. There still are some discussion

Re: Reducing the size of C++ executables - eliminating malloc

Daniel Jacobowitz wrote: > If you try what Michael's been saying, you'll notice that trivial > C++ files get the personality routine reference even if they don't > have anything with a destructor which would need cleaning up. We ought > to be able to emit (somewhat smaller) unwind information whi

Re: Reducing the size of C++ executables - eliminating malloc

On Monday 13 November 2006 00:53, Daniel Jacobowitz wrote: > On Sun, Nov 12, 2006 at 11:17:14PM +, Paul Brook wrote: > > The code being unwound through (ie. with frame data) needs to be able to > > say "I need routine X if __Unwind_Raise is used anywhere in this > > program". I'm not aware of a

Re: Reducing the size of C++ executables - eliminating malloc

On Sun, Nov 12, 2006 at 11:17:14PM +, Paul Brook wrote: > The code being unwound through (ie. with frame data) needs to be able to > say "I need routine X if __Unwind_Raise is used anywhere in this program". > I'm not aware of any way of doing this, other than trying it and starting > again i

Re: C++: Implement code transformation in parser or tree

> Of course, all this is silly if nested functions carry around their > lexical scope and can be returned. But I dont know that they do. A simple test case that would not invoke UB with n1968 lambda functions: #include typedef void (*fn_t)(); void doinvoke(fn_t f) { f(); } fn_t getit(int

Re: C++: Implement code transformation in parser or tree

>> Yes they can in fact. So the object can outlive the scope. > > As I understand the lambda proposal, the lambda function may not refer > to things that have gone out of scope. It can use *references* that > have gone out of scope, but only if the referent is still in scope. > Since the way that

Re: Reducing the size of C++ executables - eliminating malloc

Mark Mitchell wrote: But, the way the ABI works requires a reference from each unit which may cause unwinding. Even if you lose the personality routine, you will still have the exception tables, which themselves are a significant cost. If you don't want to pay for exceptions, you really have to

libffi on Macintel?

Can anyone confirm that the libffi shared libraries are properly built in gcc 4.2 branch (or trunk) on i386-apple-darwin8? I have had a report that the most recent snapshot of gcc 4.2 doesn't build libffi on Macintel boxes. This is rather disturbing since I assumed that Sandro's patches were all

Re: Reducing the size of C++ executables - eliminating malloc

Michael Eager wrote: > Mark Mitchell wrote: >> Michael Eager wrote: >>> Why should the personality routine be included in all C++ programs? >> >> Because all non-trivial, exceptions-enabled programs, may need to do >> stack unwinding. > > It would seem that the place to require the personality > r

Re: Reducing the size of C++ executables - eliminating malloc

On Sunday 12 November 2006 22:46, Michael Eager wrote: > Mark Mitchell wrote: > > Michael Eager wrote: > >> Why should the personality routine be included in all C++ programs? > > > > Because all non-trivial, exceptions-enabled programs, may need to do > > stack unwinding. > > It would seem that th

Re: Reducing the size of C++ executables - eliminating malloc

Mark Mitchell wrote: Michael Eager wrote: Why should the personality routine be included in all C++ programs? Because all non-trivial, exceptions-enabled programs, may need to do stack unwinding. It would seem that the place to require the personality routine would be in the routine which ca

Re: Reducing the size of C++ executables - eliminating malloc

Michael Eager wrote: > Mark Mitchell wrote: >>> Generating __gxx_personality_v0 is suppressed with the -fno-exceptions >>> flag, but it would seem better if this symbol were only generated >>> when catch/throw was used. This happens in cxx_init_decl_processing(), >>> which is called before it's kn

Re: Reducing the size of C++ executables - eliminating malloc

Mark Mitchell wrote: Generating __gxx_personality_v0 is suppressed with the -fno-exceptions flag, but it would seem better if this symbol were only generated when catch/throw was used. This happens in cxx_init_decl_processing(), which is called before it's known whether or not EH is really neede

Re: expanding __attribute__((format,..))

On Fri, 10 Nov 2006, Nuno Lopes wrote: > On Fri, 10 Nov 2006, Ian Lance Taylor wrote: > > > I kind of liked this idea: > > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00797.html > > but of course it was insane. > > I still think a higher level state machine as described in the > followups

Re: Reducing the size of C++ executables - eliminating malloc

Michael Eager wrote: > Preallocating space is a good thing, particularly if the size > can be computed at compile time. It's a little bit more awkward > if it has to be calculated at link time. It's a bit awkward, but it's also one of the clever tricks ARM's proprietary linker uses, and we shoul

Re: warn_unused_result attribute ignoring

On Sun, 2006-11-12 at 23:03 +0200, Timo Sirainen wrote: > If I understood correctly, newer glibcs have added warn_unused_result > attribute to several functions when compiling with -D_FORTIFY_SOURCE=2. warn_unused_result means warn if the result is unused even with (void). This warning is doing w

warn_unused_result attribute ignoring

If I understood correctly, newer glibcs have added warn_unused_result attribute to several functions when compiling with -D_FORTIFY_SOURCE=2. I think this is a good idea in general, except there are some cases where I really don't care if the call succeeds or not. Traditionally it's been possible

Re: Reducing the size of C++ executables - eliminating malloc

Mark Mitchell wrote: Michael Eager wrote: GCC 4.1.1 for PowerPC generates a 162K executable for a minimal program "int main() { return 0; }". GCC 3.4.1 generated a 7.2K executable. Mark Mitchell mentioned the same problem for ARM and proposed a patch to remove the reference to malloc in atexi

RE: gcc trunk

On Thu, 2 Nov 2006, Dave Korn wrote: >> From a user perspective, how about >> >> Current (4.1) >> Previous (4.0) >> Next (4.2) >> Active development (4.3) > Let's be user-centric. Us developers can be expected to cope. Okay. ;-) Nobody else chimed in, so I went ahead and committed the p

Re: build failure, GMP not available

On Mon, 30 Oct 2006, Kaveh R. GHAZI wrote: > Do we have a GCC FAQ somewhere? Maybe we can add GMP/MPFR build problems > and solutions there. You can add your experiences to that collection. , but I believe increasing the "intelligence" of configure and documenting al

Re: gmp/mpfr and multilib

On Nov 11, 2006, at 11:19 AM, Jack Howarth wrote: Will any of the libraries in gcc now require gmp/mpfr such that both 32-bit and 64-bit versions of gmp/mpfr must be installed? If that is the case, will the multilib build look for both a lipo 32- bit/64-bit combined shared library in $prefix/

Re: optimize option in macros or somevalue (-O2 or -O3)

Don't post to both lists, if you want to work on the compiler, gcc is fine, otherwise gcc-help. On Nov 12, 2006, at 9:29 AM, Niklaus wrote: Is there any way to specify in the code the optimization value like (-O2 or -O3) instead of on the command line. In Apple's branch, we've added support

RE: bootstrap failure on HEAD

On 12 November 2006 16:50, H. J. Lu wrote: > On Sun, Nov 12, 2006 at 02:44:36PM -, Dave Korn wrote: >> Comparing stages 2 and 3 >> warning: ./cc1-checksum.o differs >> warning: ./cc1plus-checksum.o differs >> warning: ./cc1obj-checksum.o differs >> Bootstrap comparison failure! >> ./cfg.o dif

Re: C++: Implement code transformation in parser or tree

Sohail Somani wrote: > On Fri, 2006-11-10 at 19:46 -0800, Andrew Pinski wrote: >> On Fri, 2006-11-10 at 15:23 -0800, Sohail Somani wrote: Do you need new class types, or just an anonymous FUNCTION_DECL? >>> Hi Mark, thanks for your reply. >>> >>> In general it would be a new class. If the lamb

Re: Reducing the size of C++ executables - eliminating malloc

Michael Eager wrote: > GCC 4.1.1 for PowerPC generates a 162K executable for a > minimal program "int main() { return 0; }". GCC 3.4.1 > generated a 7.2K executable. Mark Mitchell mentioned the > same problem for ARM and proposed a patch to remove the > reference to malloc in atexit > (http://so

Re: strict aliasing question

On Nov 11, 2006, at 7:56 PM, Howard Chu wrote: You probably can't, in the case of a shared library, but you probably could for a static library. I think I agree, though, a JIT can peer past a shared boundary as well. A non-JIT can as well, but it has to have some mechanism to unpeer acros

Re: subreg transformation causes incorrect post_inc

[EMAIL PROTECTED] wrote: From: Mark Shinwell <[EMAIL PROTECTED]> [EMAIL PROTECTED] wrote: My port, based on (GCC) 4.2.0 20061002 (experimental), is producing incorrect code for the following test case: [snip] I've only had a very quick look at your code, but I have a feeling thatthis is an i

optimize option in macros or somevalue (-O2 or -O3)

Hi, Is there any way to specify in the code the optimization value like (-O2 or -O3) instead of on the command line. I want #include ... ... return 0 } to be compiled with -O2 or -O3 or some better optimization than standard gcc flags like gcc a.c .I have only 1 file. The problem is i can't

Re: bootstrap failure on HEAD

On Sun, Nov 12, 2006 at 02:44:36PM -, Dave Korn wrote: > > I see this on linux but not on cygwin: > > make[3]: Leaving directory `/home/dk/gnu/obj' > Comparing stages 2 and 3 > warning: ./cc1-checksum.o differs > warning: ./cc1plus-checksum.o differs > warning: ./cc1obj-checksum.o differs >

Re: bootstrap failure on HEAD

> > I see this on linux but not on cygwin: > > make[3]: Leaving directory `/home/dk/gnu/obj' > Comparing stages 2 and 3 > warning: ./cc1-checksum.o differs > warning: ./cc1plus-checksum.o differs > warning: ./cc1obj-checksum.o differs > Bootstrap comparison failure! > ./cfg.o differs > ./cfgloopa

Re: bootstrap failure on HEAD

Dave Korn writes: >Is it just me, or does anyone else get this? I objdump'd and diff'd the >stage2 and stage3 versions of cfg.o and it seems to have developed a habit of >inserting 'shrd'/'shld' opcodes: It looks to me like the stage3 version with the shrd/shld is correct and it's that stage2 ver

Bila JPJ tak kata apa-apa....

Gempar hari ini berikut sebilangan besar pegawai JPJ tak mempedulikan apa yg berlaku sekarang, apabila pihak JPJ tidak menghiraukan org ramai memasang stiker di kenderaan berikutan pendapatan lumayan yang diperolehi hasil stiker yg ditampal anda dan cuba juga? cuma lengkap beberapa m

bootstrap failure on HEAD

I see this on linux but not on cygwin: make[3]: Leaving directory `/home/dk/gnu/obj' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs Bootstrap comparison failure! ./cfg.o differs ./cfgloopanal.o differs ./loop

Re: strict aliasing question

Howard Chu <[EMAIL PROTECTED]> writes: > As I recall, we chose int[] for alignment reasons, figuring we'd have no > guarantees on the alignment of a char[]. Neither you have on int[]. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürn

Re: strict aliasing question

Dave Korn wrote: On 12 November 2006 04:16, Howard Chu wrote: Dave Korn wrote: f = (struct foo *)(void *)buf; That's good, but why is it safe? Passing through void* means gcc has to assume it could alias anything, IIUIC, as a result of the standard allowing