Richard Guenther wrote:
Jeffrey D. Oldham wrote:
Richard Guenther wrote:
Jeffrey D. Oldham wrote:
There are still a lot of gcc 2.95 and related compilers in use
today. I prefer to leave them but let them rot unless there is a
compelling reason to remove them now.
I see. I'd remove them only to unclutter the source and maybe
increase maintainability if formally stating we require an ISO
conformant compiler. Oh - we do so already:
<quote README>
This version incorporates other minor source code changes to support
compilation using g++ version 3.1 and some improvements to POOMA
Fields. Compilation using g++ version 2.96 is no longer supported.
g++ version 3.1 is freely available at http://gcc.gnu.org/. POOMA has
also been tested using KAI C++ 4.0e.
</quote>
Richard.
Good point. Support for gcc 3.4 differs from support for gcc 3.x.y,
x < 4, because 3.4 will correctly parse some constructs that gcc
3.x.y does not. What do you prefer we write in the README for a
Pooma 2.5 release? That should drive our code changes.
I think we should state that we require a ISO standard conforming
compiler and standard library. But we should restrict ourselves to
using those parts of the standard that are supported by all recent
compilers (gcc 3.3, Intel 7.2). I.e. we don't use template template
parameters.
But working around missing std::min/max or std::complex. Requiring to
code like Utilities/Algorithms.h:
template <class DataIterator, class KillIterator>
inline
#if POOMA_NONSTANDARD_ITERATOR
typename std::iterator_traits<DataIterator>::distance_type
#else
typename std::iterator_traits<DataIterator>::difference_type
#endif
delete_backfill(DataIterator data_begin, DataIterator data_end,
const KillIterator kill_begin, const KillIterator kill_end,
#if POOMA_NONSTANDARD_ITERATOR
typename std::iterator_traits<DataIterator>::distance_type offset = 0)
#else
typename std::iterator_traits<DataIterator>::difference_type offset
= 0)
#endif
{
...
doesn't help maintainability either.
Work on VSIPL++ demonstrates that some templated C++ code that gcc
3.4 easily supports still breaks other compilers. For example, IBM
Visual Age 6 (xlc++) can have difficulty parsing with template
arguments. Intel C++ 8.0 for IA64, which I believe is the descendant
of KAI C++, has trouble with template functions defined outside
template classes.
I think we should identify a set of compilers we can test
compatibility with ourselves and formally state we require ISO
conformance. We then can list a set of tested compilers along with
test results for them. A document describing our preferred coding
style along with usable language subset would be greatly appreciated,
too.
I can start a coding style / conformance document and produce an
initial readme for an upcoming release if you like.
Richard.
Yes, I think this is a good approach, but it's probably sufficient for
now to write one or two paragraphs in the README file describing
compilation requirements. Compilation and conformance is probably more
important and easier to write and more useful to user than a coding
style document so I would prefer to put our energies into the former if
we do not have energy for both.
gcc 3.3 and gcc 3.4 differ significantly in parsing because 3.3 uses an
LALR-based parser while 3.4 uses recursive descent. The difference is
more than just template-template parameters. Despite this, I think we
should support gcc 3.2 or 3.3 if we can.
The amount of testing is non-trivial since we have several variables:
serial v. distributed
distributed: MPI-only, Cheetah+MPI, Cheetah+MM
various compilers
I would prefer to keep the compiler list relatively short and containing
the most popular compliant compilers.
Would you be willing to start modifying the README file for a release?