Hi.
Looks good to me.
Also I hope to post new pragma handling mechanism patch in near
future. Currently I'm trying to find sparc/solaris box to make some
tests. This will require some minor changes to the parser. In
particular I plan to remove threadprivate handler from FE to a
separate handler w
On Wednesday 04 May 2005 16:40, Biagio Lucini wrote:
> On Wednesday 04 May 2005 13.34, Paul Brook wrote:
> > On Wednesday 04 May 2005 13:15, Biagio Lucini wrote
> >
> > > I have understood that at the moment some misbehaviour of the
> > > front-end prevents it, but I don't quite understand what th
On Wednesday 04 May 2005 17:40, Biagio Lucini wrote:
> On Wednesday 04 May 2005 13.34, Paul Brook wrote:
> > On Wednesday 04 May 2005 13:15, Biagio Lucini wrote
> >
> > > I have understood that at the moment some misbehaviour of the
> > > front-end prevents it, but I don't quite understand what th
On Wednesday 04 May 2005 13.34, Paul Brook wrote:
>
> On Wednesday 04 May 2005 13:15, Biagio Lucini wrote
>
> > I have understood that at the moment some misbehaviour of the front-end
> > prevents it, but I don't quite understand what the problem is. Can anyone
> > shed some light?
>
> Basically t
On Wednesday 04 May 2005 13:15, Biagio Lucini wrote:
> On Tuesday 03 May 2005 21.16, Diego Novillo wrote:
> > On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote:
> > > we have to extend the gfortran internal representation also
> >
> > Yes, initially most of the effort will be in C/C+
On Wed, May 04, 2005 at 12:15:18PM +, Biagio Lucini wrote:
> Also, talking about IR, since OpenMP is mostly unique, probably
> we just need to link the gfortran parser to the work in the
> middle-end that is currently being done, with perhaps a few
> (hopefully no) exception.
>
Yes, the FEs e
On Tuesday 03 May 2005 21.16, Diego Novillo wrote:
>
> On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote:
>
> > we have to extend the gfortran internal representation also
>
> Yes, initially most of the effort will be in C/C++ since that's
> the only parser we have so far.
>
Is ther
On Tue, May 03, 2005 at 08:48:20PM -0400, Ian Lance Taylor wrote:
> If I understand what you are saying, I am complaining about the
> specific cases where the difference is in the syntax.
>
Drat, trapped in my own web of logic and definitions ;) Yes,
that's exactly what I was saying and now I see
Diego Novillo <[EMAIL PROTECTED]> writes:
> > I personally find it kind of baffling to have the same tree code act
> > differently in GENERIC and GIMPLE, a la SWITCH_EXPR. It seems to add
> > confusion for minimal benefit. If you are suggesting that the single
> > tree code GOMP_PARALLEL have di
On Tue, May 03, 2005 at 03:59:24PM -0700, Richard Henderson wrote:
> Sure, in the same way we know what "strlen" is.
>
Excellent. I'll get rid of them then.
> > That's what I thought at first, but the standard threw me into a
> > loop when it mentioned "id-expression" instead of just
> > "ident
On Tue, May 03, 2005 at 08:23:59PM -0400, Ian Lance Taylor wrote:
> Diego Novillo <[EMAIL PROTECTED]> writes:
>
> > GENERIC
> > GOMP_PARALLEL
> >
> > GIMPLE
> > GOMP_PARALLEL
> > L1:
> > g_body
> > L2:
>
> I personally find it kind of baffling to have the same tree
Diego Novillo <[EMAIL PROTECTED]> writes:
> GENERIC
> GOMP_PARALLEL
>
> GIMPLE
> GOMP_PARALLEL
> L1:
> g_body
> L2:
I personally find it kind of baffling to have the same tree code act
differently in GENERIC and GIMPLE, a la SWITCH_EXPR. It seems to add
c
On Tue, May 03, 2005 at 05:27:26PM -0400, Diego Novillo wrote:
> > Do we gain anything over expanding this to the approprate __sync_foo
> > builtin in the front end.?
> >
> Can the optimizers tell that this is an atomic builtin? If so,
> then no, they're not necessary.
Sure, in the same way we k
On Tue, May 03, 2005 at 02:16:35PM -0700, Richard Henderson wrote:
> On Tue, May 03, 2005 at 04:42:47PM -0400, Diego Novillo wrote:
> > GENERIC
> > GIMPLE
> > GOMP_ATOMIC
>
> Do we gain anything over expanding this to the approprate __sync_foo
> builtin in the front end.?
>
Can the optim
On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote:
> I will try to look it over, right now I am very busy, and I
> don't know when I can get back. I have to remarks so far, the
> first is that we have to extend the gfortran internal
> representation also, and the second is tha
On Tue, May 03, 2005 at 04:42:47PM -0400, Diego Novillo wrote:
> GENERIC
> GIMPLE
> GOMP_ATOMIC
Do we gain anything over expanding this to the approprate __sync_foo
builtin in the front end.?
> GENERIC
> GIMPLE
> GOMP_FLUSH
Likewise.
> #pragma omp threadprivate
> -
Okie,
I will try to look it over, right now I am very busy, and I don't know when I
can
get back.
I have to remarks so far, the first is that we have to extend the gfortran
internal
representation also, and the second is that perhaps we don't have to have a 1
to 1
mapping of OMP to IL
17 matches
Mail list logo
