This is the mail archive of the
mailing list for the GCC project.
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
- From: Tobias dot Schlueter at Physik dot Uni-Muenchen dot DE
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Tobias dot Schlueter at Physik dot Uni-Muenchen dot DE,Paul Thomas <paulthomas2 at wanadoo dot fr>,Toon Moene <toon at moene dot indiv dot nluug dot nl>, fortran at gcc dot gnu dot org,gcc at gcc dot gnu dot org
- Date: Tue, 1 Nov 2005 15:37:01 +0100
- Subject: Re: Vectorizing HIRLAM 4: complicated access patterns examined.
- References: <E1EVDBS-0006ob-4S@laptop.moene.indiv.nluug.nl> <436758AA.email@example.com> <firstname.lastname@example.org> <20051101142658.GB16723@sunsite.mff.cuni.cz>
Quoting Jakub Jelinek <email@example.com>:
> On Tue, Nov 01, 2005 at 02:01:43PM +0100,
> Tobias.Schlueter@Physik.Uni-Muenchen.DE wrote:
> > [ Bringing this back to fortran@, taking the optimizer guys out of CC: ]
> > Quoting Toon Moene:
> > > I still have to construct a bug report of something that confuses the
> > > and that basically looks like this:
> > >
> > > IMPLICIT CHARACTER*8 (Y)
> > > CHARACTER*11 Y1, Y2, Y3
> > > ...
> > > YA = 'D' // Y1 // Y2(1:3) // Y3(1:3) //
> > > 1 // YB(1:5)
> > > 1
> > > Unclassifiable statement at (1)
> > >
> > > Unfortunately, if I reduce the code to this one (continued) line and the
> > > necessary declarations, it doesn't fail ;-)
> > Does this fail as long as you keep the type implicit? This reminds me of
> > another PR, where the parser would decide too early that it had seen an
> > range instead of a substring, which would lead to these kinds of niceties
> > further down the line. Unfortunately, I couldn't find this bug in
> > looks like its PR's summary is not very descriptive.
> You mean PR18833?
Yes, but I don't have time right now to investigate if this is indeed the same
parser problem. The patch for 18833 only added a special case for
EQUIVALENCEs, so it might well be.