On 13/11/13 17:32, Jeff Law wrote:
On 11/13/13 03:15, Richard Biener wrote:
You know - 'tree's were a design decision (well, just my guess - I
wasn't
around 25 years ago ...). They are a perfect match to represent an AST.
So I'd say whoever introduced that middle-end between the FEs AST
and
On Wed, Nov 13, 2013 at 5:50 PM, Jakub Jelinek wrote:
> On Wed, Nov 13, 2013 at 04:43:45PM +, Joseph S. Myers wrote:
>> On Wed, 13 Nov 2013, Jeff Law wrote:
>>
>> > On 11/13/13 08:59, Joseph S. Myers wrote:
>> > > On Wed, 13 Nov 2013, Steven Bosscher wrote:
>> > >
>> > > > Really the best plac
"Joseph S. Myers" writes:
> On Wed, 13 Nov 2013, Gaius Mulley wrote:
>
>> >> In general, for GCC development to consider requirements of your front end
>> >> or back end, getting it into the GCC repository and developing it there is
>> >> strongly recommended.
>> > Sadly, I tried multiple times i
On Wed, 13 Nov 2013, Gaius Mulley wrote:
> >> In general, for GCC development to consider requirements of your front end
> >> or back end, getting it into the GCC repository and developing it there is
> >> strongly recommended.
> > Sadly, I tried multiple times in the late 90s to bring the folks g
On 11/13/13 12:33, Gaius Mulley wrote:
I'd be delighted to see gm2 in the gcc repository. The gm2 repository
is currently in git format (changed from cvs 2 weeks ago). All fsf
copyright assignment forms have been done some years ago.
At present the gm2 master can be grafted onto gcc-4.7.3 wit
Jeff Law writes:
> On 11/13/13 11:30, Joseph S. Myers wrote:
>> On Wed, 13 Nov 2013, Gaius Mulley wrote:
>>
>>> just for completeness this also applies to Modula-2 which uses the
>>> technique of double book keeping. Not sure if this is totally relevant
>>> but gm2 needs (would like :-) the abil
On 11/13/13 11:30, Joseph S. Myers wrote:
On Wed, 13 Nov 2013, Gaius Mulley wrote:
just for completeness this also applies to Modula-2 which uses the
technique of double book keeping. Not sure if this is totally relevant
but gm2 needs (would like :-) the ability to create a SET_TYPE which
maps
On Wed, 13 Nov 2013, Gaius Mulley wrote:
> just for completeness this also applies to Modula-2 which uses the
> technique of double book keeping. Not sure if this is totally relevant
> but gm2 needs (would like :-) the ability to create a SET_TYPE which
> maps onto appropriate debugging type info
Richard Biener writes:
> On Wed, Nov 13, 2013 at 11:37 AM, Steven Bosscher
> wrote:
>> On Wed, Nov 13, 2013 at 11:10 AM, Richard Biener wrote:
>>> Well, he doesn't even consider that the exact same "tree rant" applies
>>> to frontend code.
>>
>> That's not entirely true, either. Most front ends
On 11/13/13 03:15, Richard Biener wrote:
You know - 'tree's were a design decision (well, just my guess - I wasn't
around 25 years ago ...). They are a perfect match to represent an AST.
So I'd say whoever introduced that middle-end between the FEs AST
and RTL was at fault :P (luckily I wasn't
> Other places where GENERIC provides something that no doubt seemed
> convenient originally, but is less useful when you want to ensure things
> are evaluated at exactly the time implied by language semantics, include
> SAVE_EXPRs and pre/post increment/decrement.
I'm a little skeptical here beca
> Yeah, that's why I am asking. I suppose you are refering to
> gimplify_type_sizes and the required lowering of ARRAY_REFs and
> COMPONENT_REFs? Yes, I'd not make them first class citizens
> in the GIMPLE that the optimizers see but I'm fine with having
> high-GIMPLE support for them, doing a lo
On Wed, 13 Nov 2013, Jakub Jelinek wrote:
> Note, in many cases, removing optimizations from fold-const.c leads to
> regressions on code assuming something is folded (especially in
> initializers). Sure, that is all typically undocumented GNU extensions,
> but we had several such problems in the
On 11/13/13 09:43, Joseph S. Myers wrote:
On Wed, 13 Nov 2013, Jeff Law wrote:
On 11/13/13 08:59, Joseph S. Myers wrote:
On Wed, 13 Nov 2013, Steven Bosscher wrote:
Really the best place to start IMHO would be to evict 'tree' from the
front ends. That would really be a step towards making th
On Wed, Nov 13, 2013 at 04:43:45PM +, Joseph S. Myers wrote:
> On Wed, 13 Nov 2013, Jeff Law wrote:
>
> > On 11/13/13 08:59, Joseph S. Myers wrote:
> > > On Wed, 13 Nov 2013, Steven Bosscher wrote:
> > >
> > > > Really the best place to start IMHO would be to evict 'tree' from the
> > > > fro
On Wed, 13 Nov 2013, Jeff Law wrote:
> On 11/13/13 08:59, Joseph S. Myers wrote:
> > On Wed, 13 Nov 2013, Steven Bosscher wrote:
> >
> > > Really the best place to start IMHO would be to evict 'tree' from the
> > > front ends. That would really be a step towards making the front ends
> > > indepe
On 11/13/13 08:59, Joseph S. Myers wrote:
On Wed, 13 Nov 2013, Steven Bosscher wrote:
Really the best place to start IMHO would be to evict 'tree' from the
front ends. That would really be a step towards making the front ends
independent of the rest of the compiler, and it would simplify change
On Wed, 13 Nov 2013, Steven Bosscher wrote:
> Really the best place to start IMHO would be to evict 'tree' from the
> front ends. That would really be a step towards making the front ends
> independent of the rest of the compiler, and it would simplify changes
> towards static 'tree' types.
From
On Wed, Nov 13, 2013 at 5:30 AM, Diego Novillo wrote:
> On Wed, Nov 13, 2013 at 8:25 AM, Joseph S. Myers
> wrote:
>
>> assignment in general to fix bug 58943. I'd be happy for front ends to
>> move to doing all these things themselves, rather than trying to define
>> GENERIC in a way that works
On Wed, Nov 13, 2013 at 8:25 AM, Joseph S. Myers
wrote:
> assignment in general to fix bug 58943. I'd be happy for front ends to
> move to doing all these things themselves, rather than trying to define
> GENERIC in a way that works for every language's requirements on when
> things are evaluate
On Wed, 13 Nov 2013, Eric Botcazou wrote:
> > Eric, would emitting GIMPLE from gigi make that a lot more
> > complicated? That is, would you prefer to have an even
> > higher-level early GIMPLE (considering stuff like TARGET_EXPR
> > and WITH_CLEANUP_EXPR, etc.)?
>
> This would mean privatizing
On Wed, Nov 13, 2013 at 1:07 PM, Eric Botcazou wrote:
>> Eric, would emitting GIMPLE from gigi make that a lot more
>> complicated? That is, would you prefer to have an even
>> higher-level early GIMPLE (considering stuff like TARGET_EXPR
>> and WITH_CLEANUP_EXPR, etc.)?
>
> This would mean priva
On Wed, Nov 13, 2013 at 5:37 AM, Steven Bosscher wrote:
> Really the best place to start IMHO would be to evict 'tree' from the
> front ends. That would really be a step towards making the front ends
> independent of the rest of the compiler, and it would simplify changes
> towards static 'tree'
On Wed, Nov 13, 2013 at 5:15 AM, Richard Biener
wrote:
> You know - 'tree's were a design decision (well, just my guess - I wasn't
> around 25 years ago ...). They are a perfect match to represent an AST.
Yes, of course. It may have been the right decision at the time. But
design is a dynamic
On Wed, Nov 13, 2013 at 5:10 AM, Richard Biener
wrote:
> Thus "fixing" trees would be far better as you'd win for both frontend
> and middle-end code!
For FEs, sure. I agree. But right now the focus is on fixing the
interface between FEs and the ME. One thing at a time.
Finally separating FE
> Eric, would emitting GIMPLE from gigi make that a lot more
> complicated? That is, would you prefer to have an even
> higher-level early GIMPLE (considering stuff like TARGET_EXPR
> and WITH_CLEANUP_EXPR, etc.)?
This would mean privatizing in gigi all the machinery needed to support types
with
On Wed, Nov 13, 2013 at 11:37 AM, Steven Bosscher wrote:
> On Wed, Nov 13, 2013 at 11:10 AM, Richard Biener wrote:
>> Well, he doesn't even consider that the exact same "tree rant" applies
>> to frontend code.
>
> That's not entirely true, either. Most front ends already use their
> own IL in the
On Wed, Nov 13, 2013 at 11:49:56AM +0100, Steven Bosscher wrote:
> source language? That's still true, and one reason for it is 'tree'.
> The Ada, Fortran, and even C front ends use front-end specific data
> structures for most parsed entities and only produce 'tree' from it in
> the process of gen
On Wed, Nov 13, 2013 at 11:15 AM, Richard Biener wrote:
> You know - 'tree's were a design decision (well, just my guess - I wasn't
> around 25 years ago ...). They are a perfect match to represent an AST.
I'd argue against that, but perhaps some other time, in a different thread...
> So I'd sa
On Wed, Nov 13, 2013 at 11:10 AM, Richard Biener wrote:
> Well, he doesn't even consider that the exact same "tree rant" applies
> to frontend code.
That's not entirely true, either. Most front ends already use their
own IL in the parser (only C++ uses 'tree' for everything).
What worries me most
On Tue, Nov 12, 2013 at 10:25 PM, Jeff Law wrote:
> On 11/12/13 13:35, Jakub Jelinek wrote:
>>
>> On Tue, Nov 12, 2013 at 12:59:47PM -0700, Jeff Law wrote:
>>>
>>> So I lost something like 3 hrs last night due to writing a hunk of
>>> code like this
>>>
>>> if (INTEGRAL_TYPE_P (gimple_assign_lhs (
On Tue, Nov 12, 2013 at 9:52 PM, Diego Novillo wrote:
> On Tue, Nov 12, 2013 at 3:35 PM, Jakub Jelinek wrote:
>
>> Note that we have tons of code which accept either objects or types,
>> both in the frontends and in the middle-end, so changing TREE_TYPE
>> from tree to something else is definitel
On 11/12/13 14:19, Alec Teal wrote:
The name David Malcolm comes to mind, I remember watching a GCC ...
bucket, tub, some sort of large container (pot?) talk on it.
He was replacing all the macros with a class with no virtuals (only one
data member, as used by the macros in effect) and so forth
On 11/12/13 13:35, Jakub Jelinek wrote:
On Tue, Nov 12, 2013 at 12:59:47PM -0700, Jeff Law wrote:
So I lost something like 3 hrs last night due to writing a hunk of
code like this
if (INTEGRAL_TYPE_P (gimple_assign_lhs (stmt)))
INTEGRAL_TYPE_P is a macro, which accepts everything, just adding
The name David Malcolm comes to mind, I remember watching a GCC ...
bucket, tub, some sort of large container (pot?) talk on it.
He was replacing all the macros with a class with no virtuals (only one
data member, as used by the macros in effect) and so forth and using
inheritance, doesn't tha
On Tue, Nov 12, 2013 at 3:35 PM, Jakub Jelinek wrote:
> Note that we have tons of code which accept either objects or types,
> both in the frontends and in the middle-end, so changing TREE_TYPE
> from tree to something else is definitely non-trivial.
Well, sure it's hard. This is the whole poin
On Tue, Nov 12, 2013 at 12:59:47PM -0700, Jeff Law wrote:
> So I lost something like 3 hrs last night due to writing a hunk of
> code like this
>
> if (INTEGRAL_TYPE_P (gimple_assign_lhs (stmt)))
INTEGRAL_TYPE_P is a macro, which accepts everything, just adding
a TYPE_CHECK to that macro would be
On Tue, Nov 12, 2013 at 2:59 PM, Jeff Law wrote:
> It's time to move on and do something sensible with the core parts of our
> ILs so that we're all more effective in the long run.
My sentiments, exactly!
Diego.
38 matches
Mail list logo
