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

[Oliver Sander]

If supporting (or better: testing on) old platforms helps us make the
code better, then of course we should do it.  But if it forces us to
make the code worse, and nobody is using that compiler anyways,
then I think we shouldn't.

O

Christian Engwer schrieb:
> 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
>>
>>     
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>   


-- 
************************************************************************
* Oliver Sander                ** email: sander at mi.fu-berlin.de        *
* Freie Universität Berlin     ** phone: + 49 (30) 838 75348           *
* Institut für Mathematik      ** URL  : page.mi.fu-berlin.de/~sander  *
* Arnimallee 6                 ** -------------------------------------*
* 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
************************************************************************