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

[Andreas Dedner]

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?

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
>