>
>
> My strong belief is that a compiler project as gigantic as GCC needs some kind
> of garbage collection
Can you name another compiler written in C/C++ using GC ? :)
>. I also believe that the current (4.7) garbage
> collection *implementation* (which is probably what both Diego and
> Lawrenc
On Fri, Nov 16, 2012 at 5:13 AM, Diego Novillo wrote:
> On Thu, Nov 15, 2012 at 2:31 AM, Xinliang David Li wrote:
>
>>> ssa_stmt t = q.stmt (NE_EXPR, shadow, 0);
>>> ssa_stmt a = q.stmt (BIT_AND_EXPR, base_addr, 7);
>>> ssa_stmt b = q.stmt (shadow_type, a);
>>> ssa_stmt c = q.stmt (PLUS_EXPR, b,
I think the field "htab_t original_pddrs" in struct scop in
graphite-poly.h is unused. A macro to access that field is also
unused.
/* A SCOP is a Static Control Part of the program, simple enough
to be represented in polyhedral form. */
struct scop
{
...
/* A hashtable of the data depend
Snapshot gcc-4.6-20121116 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20121116/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Fri, Nov 16, 2012 at 6:30 AM, Michael Matz wrote:
> Hi,
>
> On Fri, 16 Nov 2012, Diego Novillo wrote:
>
>> > I think consistency should trump brevity here, so also add a tree code for
>> > the converter, i.e.
>> > ssa_stmt b = q.stmt (NOP_EXPR, shadow_type, a);
>>
>> Ah, yes. This one was am
Piotr Wyderski wrote:
Dodji Seketeli wrote:
That, and [dcl.typedef]/6 says:
In a given scope, a typedef specifier shall not be used to redefine
the name of any type declared in that scope to refer to a different
type.
So, I tend to think that GCC is right here.
Right *where*?
On Fri, Nov 16, 2012 at 7:15 AM, Piotr Wyderski
wrote:
> Dodji Seketeli wrote:
>
>> That, and [dcl.typedef]/6 says:
>>
>> In a given scope, a typedef specifier shall not be used to redefine
>> the name of any type declared in that scope to refer to a different
>> type.
>>
>> So, I tend
On Fri, Nov 16, 2012 at 9:42 AM, Andrew MacLeod wrote:
> PS I'd also prefer the term 'memory pool' or something... the term 'obstack'
> still makes my skin crawl :-)
Amen.
-- Gaby, old enough to remember the obstack days
On 11/15/2012 07:59 PM, Diego Novillo wrote:
At this point, we are trying to reach consensus on the general
direction that we should take. Given how intertwined GC and PCH
are, the choices we make for one affect the other.
We don't have a strong preference at the moment, but we are
leaning in
Dodji Seketeli wrote:
> That, and [dcl.typedef]/6 says:
>
> In a given scope, a typedef specifier shall not be used to redefine
> the name of any type declared in that scope to refer to a different
> type.
>
> So, I tend to think that GCC is right here.
Right *where*? In case of the s
On Fri, Nov 16, 2012 at 2:06 AM, Basile Starynkevitch
wrote:
>
> My strong belief is that a compiler project as gigantic as GCC needs some kind
> of garbage collection.
I suspect that is correct, especially given the way the compiler is
currently implemented. But I also suspect that we could use
Hi,
On Fri, 16 Nov 2012, Diego Novillo wrote:
> > I think consistency should trump brevity here, so also add a tree code for
> > the converter, i.e.
> > ssa_stmt b = q.stmt (NOP_EXPR, shadow_type, a);
>
> Ah, yes. This one was amusing. When we were drafting the proposal,
> Lawrence kept wond
On Fri, Nov 16, 2012 at 5:06 AM, Basile Starynkevitch
wrote:
> On Thu, Nov 15, 2012 at 07:59:36PM -0500, Diego Novillo wrote:
>> As we continue adding new C++ features in the compiler, gengtype
>> is becoming an increasing source of pain. In this proposal, we
>> want to explore different approach
On Thu, Nov 15, 2012 at 9:48 AM, Michael Matz wrote:
> Hi Lawrence,
>
> On Wed, 14 Nov 2012, Lawrence Crowl wrote:
>
>> Diego and I seek your comments on the following (loose) proposal.
>
> In principle I agree with the goal, I'm not sure I like the specific way
> yet, and even if I do I have some
On Thu, Nov 15, 2012 at 1:06 AM, Basile Starynkevitch
wrote:
> On Wed, Nov 14, 2012 at 05:13:12PM -0800, Lawrence Crowl wrote:
>> Diego and I seek your comments on the following (loose) proposal.
>>
>>
>> Generating gimple and tree expressions require lots of detail,
>> which is hard to remember a
On Thu, Nov 15, 2012 at 2:31 AM, Xinliang David Li wrote:
>> ssa_stmt t = q.stmt (NE_EXPR, shadow, 0);
>> ssa_stmt a = q.stmt (BIT_AND_EXPR, base_addr, 7);
>> ssa_stmt b = q.stmt (shadow_type, a);
>> ssa_stmt c = q.stmt (PLUS_EXPR, b, offset);
>> ssa_stmt d = q.stmt (GE_EXPR, c, shadow);
>> ssa_s
On Wed, Nov 14, 2012 at 8:48 PM, Andrew Pinski wrote:
> Here is my proposal though I don't have time to work on it. Make some
> python scripts which do the basic function of the debug_* functions.
No. Debug traces and -fdump-* support.
Python pretty printers for gdb would be great, of course.
On Fri, Nov 16, 2012 at 4:38 AM, Martin Jambor wrote:
> So you do not plan to replace/rename at least some of them? This
> seems like unnecessary and confusing layering just to avoid the work
> to do the right thing.
No, we plan to replace all the existing dumping routines. We are just
not pla
Hi,
On Thu, 15 Nov 2012, Lawrence Crowl wrote:
> They allow us to use the same name for the same actions in two
> different contexts. In particular, distinguishing between statement
> construction in SSA and non-SSA.
I don't see the difference, and I don't see where you need context data to
di
Diego Novillo wrote:
> === Approach: Move GTY to cc1plus.
>
> Instead of a separate weak parser, we would make cc1plus understand GTY
> attributes. The compiler would emit IL in the object files instead of
> generating source.
Does this mean GTY is implemented as a C++ language extension and th
Basile Starynkevitch wrote, On Friday 16 November 2012 03:36 PM:
To be more specific, I call garbage collection a scheme where (small newbie)
GCC contributors
can contribute easily some code to GCC without having to understand when, and
how precisely,
some data will be freed. If a user adds
> === Approach: Use the Boehm collector.
>
> The general approach is to define allocation and deallocation
> functions to the Boehm collector that handle memory within the
> PCH range. We would also provide a class to register global
> roots at the point of declaration of those roots. We would lik
On Thu, Nov 15, 2012 at 07:59:36PM -0500, Diego Novillo wrote:
> As we continue adding new C++ features in the compiler, gengtype
> is becoming an increasing source of pain. In this proposal, we
> want to explore different approaches to GC that we could
> implement.
Just a minor remark: we don't
Hi,
On Wed, Nov 14, 2012 at 05:12:15PM -0800, Lawrence Crowl wrote:
> Diego and I seek your comments on the following (loose) proposal.
>
>
> It is sometimes hard to remember which printing function is used
> for debugging a type, or even which type you have.
Yeah, from time to time a still nee
Jiri Palecek a écrit:
> Ulf Magnusson wrote:
>> On Wed, Nov 14, 2012 at 6:10 PM, Piotr Wyderski
>> wrote:
>>> The following snippet:
>>>
>>> class A {};
>>> class B : public A {
>>>
>>> typedef A super;
>>>
>>> public:
>>>
>>> class X {};
>>> };
>>>
>>>
>>> class C : public B {
>>>
>>>
25 matches
Mail list logo
