From 72963d16442c49099c4e1cfce263bcb480bc7a5a Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Wed, 18 Jun 2003 23:05:01 +0000 Subject: [PATCH] Note that it still doesn't work with pgcc 4.1. git-svn-id: https://svn.dealii.org/trunk@7805 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/doc/platforms/pgcc.html | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/deal.II/doc/platforms/pgcc.html b/deal.II/doc/platforms/pgcc.html index 7cbb38b7b7..929b5a437b 100644 --- a/deal.II/doc/platforms/pgcc.html +++ b/deal.II/doc/platforms/pgcc.html @@ -80,5 +80,37 @@ pgCC-Fatal-/home/wolf/bin/pgcc/linux86/bin/pgcpp1 TERMINATED by signal 6

+

+ When the next version came (4.0), we found the front-end much + improved. However, the real showstopper is that for this code + +

+    template <int dim> struct C {
+      void f();
+    };
+
+    template <> void C<1>::f() {};
+    
+ + no code is generated for C<1>::f unless the + function is used later on in the file. In contrast to + non-specialized template functions, this case is also not handled + by pgcc's prelinker which would otherwise instantiate missing + templates. Since we have many (many many) specializations of + member functions in the .cc files in the library, that means that + code for these functions is never generated. Consequently, one + gets linker errors later on. +

+ +

+ We believe that pgcc's behavior is not in accordance with the + standards, and is also not useful, since it forces the programmer + to put explicit specializations of functions into header files. We + had a long email exchange with Portland Group people in the summer + of 2002, who promised to review the matter. Unfortunately, the + problem still exists in pgcc 4.1 as of June 2003, making pgcc + still unusable to compile deal.II. +

+ -- 2.39.5