Re: [PATCH] PowerPC64 port part 1 of 7

[Roland McGrath <roland at frob dot com>]

You should use the machine names emitted by config.sub, not ones of your
own making.  The canonical names are powerpc64 and powerpc.  For files in
sysdeps/powerpc that are overridden by new powerpc64 files, I don't see a
real reason to move the existing files to a new subdir, though it doesn't
hurt and it matches what was done for sparc.  If there is a need for a
32-bit-only directory, then it should be called powerpc32 (cf sparc32).

If GNU-common files like config.sub and config.guess need to be changed,
then you need to get the changes folded into the master versions of those
files (I think those two live with GCC now, not positive) and then we will
put the new canonical versions into libc.

I understand it is easiest for you to send in large patches en masse, and I
appreciate the benefit of delivering a single set of changes that actually
results in a working port.  But that is not what makes it easy for us to
examine and approve each change as we must.  First, you need to submit each
topically distinct set of changes to machine-independent code individually
with log entries that are clear and complete on their own, and with
sufficient explanation for us to see why you need them.  (Explanations for
why things need to be the way they are should primarily be in comments,
secondarily in log entries, and only tertiarily in email.)

Many of your log entries are not carefully written and formatted to GNU
conventions.  As well as appropriate spacing, they should have lines filled
to <80 chars.  They must identify what particular parts of the code were
changed (function names, etc) and explicitly list names of affected things
rather than "32-bit-dependent entries" and the like.  Please observe the
canonical form using (a, b) to list affected functions (or other meaningful
entities) and [...] to cite conditional code.

Platform-specific changes rarely belong in the top-level configure or
Makeconfig (aside from the base_machine table) or in
sysdeps/unix/sysv/linux files.  Use
sysdeps/unix/sysv/linux/powerpc/powerpc64/configure and .../Makefile
and such.

Can you write an autoconf test that properly discerns
HAVE_ASM_GLOBAL_DOT_NAME by using the compiler rather than presuming based
on platform?

Since 2.2.5 has already sailed, the appropriate earliest version set to use
is 2.2.6 unless there was a preexisting release version on this platform
that started at 2.2.5.

These are just a few things I have seen in a cursory look over your patches.
If the changes come with better granularity and better log entries, it will
be easier to notice other problems.