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

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

chives? Thanks, Sohail

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

be difficult unless you can use typeof. I think a new intermediate tree type would be beneficial. Atleast one pass is necessary after the object is constructed to enable the nested function optimization. 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. Thanks for your reply, Sohail

Re: Threading the compiler

> Each of the functions in a C/C++ program is dependent on > the global environment, but each is independent of each other. > Separate threads could process the tree/RTL for each function > independently, with the results merged on completion. This > may interact adversely with some global optimiz

Re: Threading the compiler

% in less time. I think it sounds like (from what you say) that gcc needs to be optimized before parallelized? In some cases this might be easier. Sohail

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

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

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

On Fri, 2006-11-10 at 14:47 -0800, Mark Mitchell wrote: > Sohail Somani wrote: > > > struct __some_random_name > > { > > void operator()(int & t){t++;} > > }; > > > > for_each(b,e,__some_random_name()); > > > > Would this require a n

Re: Threading the compiler

pers in particular of course. Aside: I think the RAII nature of C++ constructors/destructors is helpful in locking code. More 2c? Sohail

Re: Threading the compiler

g similar for us. What parts could be done in parallel besides things that can be done by make -j80? I would guess that certain tree transformations could be run in parallel. Do threads help for io-bound apps? Thanks, Sohail

Re: Threading the compiler

I don't think it can possibly hurt as long as people follow normal C++ coding rules. The main issue is not really language choice though. The main issues would likely be defining data to be isolated enough to be useful to do work in parallel. Lots of threads communicating a lot would be bad. Sohail

cp_parser_parameter_declaration_clause

rror occurred while parsing the parameter-declaration-list, then the entire parameter-declaration-clause is erroneous. */ if (is_error) return NULL; So how does one tell if this function has returned an error? Thanks, Sohail

Re: Obtaining type equivilance in C front end

On Thu, 2006-11-09 at 06:17 +, Brendon Costa wrote: > How do i determine if two type nodes in the C front end are equivilent? > In C++ i use same_type_p() but do not see an equivilant for the C front end. Hi Brendon, Wouldn't the C++ one (mostly) be a superset of the C? Thanks, Sohail

C++: Implement code transformation in parser or tree

(int & t){t++;}); would become: struct __some_random_name { void operator()(int & t){t++;} }; for_each(b,e,__some_random_name()); Would this require a new tree node like LAMBDA_FUNCTION or should the parser do the translation? In the latter case, no new nodes should be necessary (I think). Thanks! Sohail