Re: 3.1.52 fails to build in hppa/linux

[John W. Eaton]

On 22-Feb-2009, Jaroslav Hajek wrote:

| The easiest way to get it is to cd to liboctave/, do
| make pic/oct-inttypes.o
| 
| then copy the command shown to compile, but replace "-c" by "-E" and
| redirect -o to a suitable file. It will be probably too large to post
| it on the mailing list.

You can also add -save-temps to CXXFLAGS.  That will cause gcc to
generate an oct-inttypes.ii file for octave-inttypes.cc.  So just cd
to the liboctave directory in your build tree and run

  rm -f pic/oct-inttypes.o
  make CXXFLAGS="-g -O2 -save-temps" pic/oct-inttypes.o

| Anyway, I think I just found another bug in gcc. The following does not 
compile:
| 
| #include <iostream>
| class A
| {
| public:
|   class B {};
|   template <class T, class X> void x(X a) { std::cout << a; }
|   template <class T> void x(int a);
| };
| 
| template <class T>
| void A::x (int a)
| {
|   std::cout << 'x' << a;
| }
| template void A::x<A::B> (int a);
| 
| The second explicit instantiation is not accepted. (Can you
| confirm?...) In fact, g++ does not even recognize it as an explicit
| instantiation, but instead gripes about ambiguous specialization, just
| like in the error messages you've shown.
| I'll try to inspect the C++ standard whether this is really valid (but
| it seems so), and then maybe file a bug for GCC.
| The code is accepted by Intel C++ 11.0, as well as the online Comeau
| C++ checker, hence I'm fairly convinced it is correct even without
| inspecting the standard.
| 
| Sigh. While I was reluctant to provide workarounds for gcc 3.x, bug in
| 4.3 is a different beast - that is probably something worth the
| trouble... isn't it? Opinions?

Yeah, it would be bad if Octave doesn't build with the latest GCC,
even if it is only fails on some platforms.  This would cause trouble
for getting Octave into Debian testing, for example.

Assuming these are bugs in GCC, can anyone easily check to see if they
are fixed in the current GCC sources (what will become GCC 4.x)?

jwe