Work around the following bug in Sun's Forte compiler, by simply
adding a private inheritance of B1. Since that base class only has
static members, that does not hurt anyway.
/* ------------------------------------------------- */
/* Problem 17 -- access control: compiler error */
/* Error: B1::dim is not accessible from B1::X<2>. */
/* Where: While specializing "B1::X<2>" */
/* Where: Specialized in non-template code. */
/* Note that "dim" should actually be placed with */
/* B1::X, rather than with B1. */
template <typename T> class V {};
struct B1 {
template <int dim> struct X {
int i[dim];
};
};
struct B2 : private B1 {};
struct D : public B2, private B1 {
~D () {};
typedef B1::X<2> X;
V<X> x;
};
Work around a bug in Sun's Forte compiler. The code in question was
dangerous anyway, and since this is no performance critical place, we
take the plunge.
Detect and work around the following bug in pre-3.0 gccs:
struct X
{
template <typename T2>
X operator = (T2 &) {return *this;};
};
template X X::operator=<> (float &);
These compilers reported
x.cc:7: 'operator =' not defined
x.cc:7: confused by earlier errors, bailing out
and wanted that we write
template X X::template operator=<> (float &);
instead. This is not what the standard prescribes, and is also not necessary for regular member functions.
Unfortunately, we cannot simply add that 'template' here, since otherwise Sun's Forte compiler no more
groks this. So we define a symbol DEAL_II_MEMBER_OP_TEMPLATE_INST which is empty for standards
compliant compilers, or 'template' in case of broken gcc's.
Detect and work around the following bug:
dnl /* ----------------------------------------------- */
dnl /* Problem 14: Access control. Friendship is not */
dnl /* granted although explicitly declared. */
dnl template <int N, int M> class T { void bar (); };
dnl
dnl template <int M> class T<1,M> {
dnl private:
dnl static int i;
dnl template <int N1, int N2> friend class T;
dnl };
dnl
dnl template <int N,int M> void T<N,M>::bar () {
dnl T<N-1,M>::i;
dnl };
dnl
dnl template class T<2,1> ;
We work around by making a certain function in the Tensor<1,dim> class public.
Work around a really ugly bug in Suns Forte compiler, which manifests itself at the following testcase:
/* ---------------------------------------------------------- */
/* Internal compiler error in abi2_mangler::entity_expression */
/* when compiled with -g. */
template < int dim > struct T {
typedef T<dim-1> SubT;
T (SubT);
};
template <int dim> T<dim>::T (SubT) {};
template class T<3> ;
If compiled with -g, the compiler gets an internal compiler error...
When we forward declare the general Tensor template, also declare that it has a partial specialization. Otherwise, Sun Forte is confused, but I believe rightfully so. Unfortunately, its error messages are less than helpful in this case...
Work around a problem of Suns Forte compiler which cant handle the case that an enum or a class in a namespace has the same name as the namespace itself, as in
/* ----------------------------------------------- */
/* Problem 10 -- Members with the same name as the */
/* enclosing namespace. */
namespace NS3 {
class NS3 {};
};
NS3::NS3 ns3;
Thus rename the IteratorState enum in the IteratorState namespace into IteratorState_s_.
Work around a problem of Suns Forte compiler which cant handle the case that an enum or a class in a namespace has the same name as the namespace itself, as in
/* ----------------------------------------------- */
/* Problem 10 -- Members with the same name as the */
/* enclosing namespace. */
namespace NS3 {
class NS3 {};
};
NS3::NS3 ns3;
Thus rename the IteratorState enum in the IteratorState namespace into IteratorState_s_.
Work around a problem in Suns Forte compiler, which choked on the explicit qualification of a member template when that member template is an operator, as in
/* --------------------------------------- */
/* Problem 9 -- selecting member templates */
/* by template keyword */
/* (Why does it make a difference whether */
/* member function or operator?) */
class T7 {
template <typename T> void operator << (T);
template <typename T> void f (T);
void g() {
this->template f<int> (1); // OK!
this->template operator<< <int> (1); // not!
};
};
Work around by introducing a common function for the template and the nontemplate function.
Work around a problem of the Sun Forte compiler that chokes on some trailing semicolons, like in
/* ---------------------------------------- */
/* Problem 1 -- extraneous semicolon? */
/* (Why does this go away if not a template */
/* or in a namespace?) */
namespace NS1 {
template <class T>
void test () {};
};
/* ---------------------------------------- */
/* Problem 2 -- extraneous semicolon? */
/* (Why for inner but not outer namespace?) */
namespace NS2 {
namespace NS3 {};
};
Suns Forte compiler chokes on template argument computations, like in
/* ----------------------------------------------- */
/* Problem 5 -- no computations with template args */
template <int dim> struct T2 {};
template <int dim> T2<dim-1> g(T2<dim>) {};
Fix this by introducing a new type local to the class that uses it.
Remove semicolons to work around a bug in Sun Forte. Testcase:
/* ---------------------------------- */
/* Problem 1 -- extraneous semicolon? */
namespace NS1 {
template <class T>
void test () {};
};
Avoid friend declaration of typedefs. Testcase:
/* -------------------------------- */
/* Problem 6 -- friend and typedefs */
class T3;
class T4
{
typedef T3 Tloc;
friend class Tloc;
};
Move implementations to .cc file, since not used very often anyway and
thus no point to mark inline. change triggered by Sun Forte 6.2's
inability to first declare a function, then define it marked
inline. testcase:
Significantly change the way configure works. Mostly, configure.in is now only a list of task to be done, cleanly separated into several categories. The actual work is done by macros in aclocal.m4. Also, config.guess and alike have been banned from the top-level directory and are now in contrib/config.
Disabling variable cache leads to abort here. Since no cache is used anyway since top-level configure doesn't use it, theres no point in mentioning that here.
In an assertion, it was checked whether vertex dof indices for
different children of a face matched each other, for consistency. This
failed if the FE in use does not have dofs on vertices at all. Check
for the vertex index instead of the vertex _dof_ index now.
In an assertion, it was checked whether vertex dof indices for
different children of a face matched each other, for consistency. This
failed if the FE in use does not have dofs on vertices at all. Check
for the vertex index instead of the vertex _dof_ index now.