On Wed, Oct 9, 2013 at 11:34 PM, Andrew MacLeod wrote:
> On 10/09/2013 02:18 PM, Andrew MacLeod wrote:
>>
>> On 10/09/2013 02:15 PM, Andrew MacLeod wrote:
>>>
>>>
>>> Fair enough. I'll adjust... the front end files which use that routine
>>> will just have to include gimplify.h
>>>
>> Unless ma
On 10/09/2013 02:18 PM, Andrew MacLeod wrote:
On 10/09/2013 02:15 PM, Andrew MacLeod wrote:
Fair enough. I'll adjust... the front end files which use that
routine will just have to include gimplify.h
Unless maybe we should expand the gimplify module to have a
gimplfy-fe.[ch] which includ
On 10/09/2013 02:15 PM, Andrew MacLeod wrote:
On 10/09/2013 01:48 PM, Richard Biener wrote:
Andrew MacLeod wrote:
On 10/08/2013 06:22 AM, Richard Biener wrote:
unvisit_body isn't generic enough to warrant moving out of gimplify.c
(the only user).
Bah, now I remember.. so there *are* other us
On 10/09/2013 01:48 PM, Richard Biener wrote:
Andrew MacLeod wrote:
On 10/08/2013 06:22 AM, Richard Biener wrote:
unvisit_body isn't generic enough to warrant moving out of gimplify.c
(the only user).
Bah, now I remember.. so there *are* other users.. this routine is
called from various front
Andrew MacLeod wrote:
>On 10/08/2013 06:22 AM, Richard Biener wrote:
>>
>> unvisit_body isn't generic enough to warrant moving out of gimplify.c
>> (the only user).
>
>Bah, now I remember.. so there *are* other users.. this routine is
>called from various front ends.. fortran, c-family and cp all
On Wed, Oct 9, 2013 at 11:37 AM, Andrew MacLeod wrote:
> bootstraps on x86_64-unknown-linux-gnu, regressions test are still running.
> OK?
Sure.
On 10/08/2013 06:22 AM, Richard Biener wrote:
unvisit_body isn't generic enough to warrant moving out of gimplify.c
(the only user).
Bah, now I remember.. so there *are* other users.. this routine is
called from various front ends.. fortran, c-family and cp all call it.
That is why I wanted
On Wed, Oct 9, 2013 at 1:31 AM, Andrew MacLeod wrote:
> On 10/08/2013 07:44 AM, Andrew MacLeod wrote:
>>
>> On 10/08/2013 06:22 AM, Richard Biener wrote:
>>>
>>> graphite.h should be unnecessary with moving the pass struct like you
>>> did for other loop opts. Likewise tree-parloops.h (well, ok,
On 10/08/2013 07:44 AM, Andrew MacLeod wrote:
On 10/08/2013 06:22 AM, Richard Biener wrote:
graphite.h should be unnecessary with moving the pass struct like you
did for other loop opts. Likewise tree-parloops.h (well, ok, maybe
you need parallelized_function_p, even though it's implementation
On 10/08/2013 06:22 AM, Richard Biener wrote:
On Fri, Oct 4, 2013 at 6:52 PM, Andrew MacLeod wrote:
This patch clears the rest of the improperly located prototypes out of
tree-flow.h. A bit larger than the last few, but I was pushing to clear
this up, and its not quite as bad as it seems :-)
On Fri, Oct 4, 2013 at 6:52 PM, Andrew MacLeod wrote:
> This patch clears the rest of the improperly located prototypes out of
> tree-flow.h. A bit larger than the last few, but I was pushing to clear
> this up, and its not quite as bad as it seems :-)
>
> Of interest:
>
> * tree-flow.h now conta
11 matches
Mail list logo