[Dune] [Dune-Commit] dune-localfunctions r828 - in trunk/dune/localfunctions: common lagrange test

[Christian Engwer]

On Fri, Feb 12, 2010 at 03:57:06PM +0100, Andreas Dedner wrote:
> Of course I would agree that xlc would be good to have on the support list.
> But is there any direct correspondence between gcc 3.4 and xlc?
> I think that especially testing with gcc 3.4 although we are close to
> having a gcc 4.5 is unnecessary - bur is adding a test for xlc (if
> possibl)e not
> a different issue?

Especially the tests for 3.4 showed some places where I was astonished
that gcc 4.x did compile these. I still think that the code was just
wrong and with this test we would have never found out. I agree that
there is no need to keep a big burden if it's not necessary, but atm I
don't think that gcc 3.4 is such a big burden.

The fixes for icc-10 on the other hand are fare from nice and break
major party of the concept.

Christian

> Andreas
> 
> Markus Blatt wrote:
> >Hi,
> >
> >On Fri, Feb 12, 2010 at 02:25:42PM +0100, Oliver Sander wrote:
> >>I agree with this.  Do we know of actually users who need the backward
> >>compatibility and cannot stay with Dune 1.2.2 at the same time?
> >>
> >>
> >>Andreas Dedner schrieb:
> >>>Hi,
> >>>I think we have to discuss to what extend we really want to still
> >>>support these old compiler - especially icc 7 and gcc 3.4.
> >>>Could somebody who really uses them comment on this. For example
> >>>in Karlsruhe on their cluster they have gcc 4.2 and icc 12.
> >>>We said we wanted to have the compatibility for 2.0 and lets go ahead
> >>>with that but some of the fixes checked in to manage this have  not been
> >>>very nice code and if nobody requires the old compiler I would
> >>>suggest to revert some of the changes (e.g. in
> >>>dune-lf/dune/lf/utility/field.hh)
> >>>in the trunk and to drop those old compilers from the compatibility list
> >>>for the next release.
> >>>Best
> >>>Andreas
> >
> >
> >While I agree that few people use this compilers, I still think
> >dropping support for them is not the way to go. The more compilers we
> >support the more standard compliant we are. In the last weeks several
> >non standard-conformant things were patched due to supporting these
> >rather old compilers.
> >
> >My fear is that if we drop support we will maybe not drop standard
> >conformance, but use more and more features that are just supported by
> >the leading pack of the compilers. This would prevent other compilers
> >(e.g. IBM's xlc) from catching up.
> >
> >There are compilers on supercomputers (xlc on the Blue Gene) that I
> >would like to see being supported by Dune. IMO support here means giving
> >them time to implement the standard correctly before DUNE moves to the
> >next standard.
> >
> >Having said that, I agree that using typedefs in code to do this is a
> >real pain and not beautiful/readable etc.
> >
> >Just my 2 cents.
> >
> >Marus
> >
> >_______________________________________________
> >Dune mailing list
> >Dune at dune-project.org
> >http://lists.dune-project.org/mailman/listinfo/dune
> 
> 
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>