Older blog entries for lerdsuwa (starting at number 58)

GCC

Finished some friend class injection work (Patch 1 and Patch 2). Now I have to decide which issue to fix next. One is about name injection during template instantiation (Bug 4403). The other is hiding injected name (Bug 1016).

Yuck! the attempt to fix friend lookup bug failed because it was based on lookup_tag function. It could only find types and completely ignore typedef and template type parameter, so it can't diagnose invalid codes like:

  template <class T> class A {
    typedef int U;
    friend class T; // Invalid
    friend class U; // Invalid
  };

Now I have to figure out the implementation based on lookup_name function which will find all such names. And the result will have to be checked for validity. :(

Start working on GCC friend name lookup and name injection issues such as bug 14513. The current fix for this bug looks promising a patch could be ready in a few days.

This is unlike the previous one where I spent about a week playing with template specialization of nested class (bugs 4882, 13088, etc.). They turned out to be a real pain. Those are back to the shelf.

The patch member class as template friend is finished and posted. I ended up using typename for both code cases mentioned in the previous diary:

template <class T> class C {
  friend class D<T>::X;
  template <class U> friend class D<U>::Y;
};

I used the fact that, after instantiation of C such as C<int>, the first one become template-parameter non-dependent while the other still depends on the template parameter U.

GCC

After some experiment, using typename for internal representation is not enough. It cannot distinguish between the following two cases:

template <class T> struct D { ... };
template <class T> class C {
  friend class D<T>::X;                    // use typename here?
  template <class U> friend class D<U>::Y; // also use typename?
};

My latest idea is to invent a new tree node to represent the second friend.

I find myself reviewing yet another C++ book. This time it's a new edition, not a new book. So it's already in a good shape and doesn't need much comment. This makes my work a lot easier.

For GCC, I just get back to member class as template friend feature as in code like

class C {
  template <class T> friend class A<T>::X;
}

One more step is accomplished: checking class-key syntax error for codes like

template <class T> class C {
  friend typename T::X;     // Syntax error
  friend typename T::X f(); // OK
};

is moved to parser. The new friend feature requires the same internal representation as 'typename' so the diagnostics of such error cannot be performed in later stages. Next step: making friend codes able to handle the typename representation.

Back to GCC hacking. The patch for bug 13092 is finally accepted and committed to the mainline.

I work on member class as template friend feature to compliment the work earlier on member function. It can deal with simpler cases now, but some more thought is necessary for advanced cases. May be a few week to go before a patch is ready.

As a break, I look at a few template template parameter bugs reported. Fixing them is not as hard as the template friend feature above and take only a day or two each. In fact one is fixed already and I am testing a patch for the next one.

Reviewing the C++ book is eating all my time. After it's finished, which should be very soon, then it's time to go back to GCC hacking. A new development version of kcd will be out too.

GRhino
It turned out that the hashing used in GRhino failed to take into account two problems:

• The board score depends on who has the next move. The comes from the parity evaluator.
• The range of score computed may be limited due to alpha-beta pruning and it not accurate when reused during evaluation of next moves.

Both are fixed and the result is GRhino 0.12.0. Verifying that the search algorithm runs correctly will be dealt with some time later. Next version will have game save/load features and may be timed game if I can finalize on the layout of the clocks on the board window.

Figured out what to do next with GRhino - fixing the AI :) After playing with alpha-beta pruning and end game searching tests, it turned out that incorrect hashing is the source of AI weakness. The hash-disabled GRhino beats the latest GRhino release version all the time. The next part is to find out why the hash is corrupt, which is again not easy.