Hints for backporting gcc 4.5 powerpc fix to gcc 4.4.3?

[Simon Baldwin]

I'm currently trying to backport a small part of gcc 4.5 r151729 to
gcc 4.4.3.  This revision fixes a problem in powerpc code generation
that leads to gcc not using lmw/stmw instructions in function prologue
and epilogues, where it could otherwise validly use them.

On the face of things, the central piece of r151729 I seem to want is just this:

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 151728)
+++ gcc/config/rs6000/rs6000.c  (revision 151729)
@@ -18033,7 +18033,8 @@ static bool
 no_global_regs_above (int first, bool gpr)
 {
   int i;
-  for (i = first; i < gpr ? 32 : 64 ; i++)
+  int last = gpr ? 32 : 64;
+  for (i = first; i < last; i++)
 if (global_regs[i])
   return false;
   return true;

Taking only that and leaving out all of the rest of r151729 lets me
build a powerpc gcc that does use lmw/stmw instructions in function
prologue and epilogues as hoped.  Unfortunately it also has bad
codegen elsewhere.  So it seems I need more than just this little
piece of r151729.  Unfortunately, r151729 is a fairly large patch that
seems to do a number of jobs and which does not apply readily to gcc
4.4.  At the moment it's not clear to me what other parts of it I
might need.

Can anyone here offer any hints or pointers on how to extract from the
r151729 diff just the few pieces needed to fix this single powerpc
codegen bug in gcc 4.4.3?  Anyone recognize this issue and already
dealt with it in isolation?

Thanks.

--
Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
Palace Road, London SW1W 9TQ | Registered in England Number: 3977902

Re: Hints for backporting gcc 4.5 powerpc fix to gcc 4.4.3?

[David Edelsohn]

On Tue, Mar 22, 2011 at 9:25 AM, Simon Baldwin  wrote:
> I'm currently trying to backport a small part of gcc 4.5 r151729 to
> gcc 4.4.3.  This revision fixes a problem in powerpc code generation
> that leads to gcc not using lmw/stmw instructions in function prologue
> and epilogues, where it could otherwise validly use them.
>
> On the face of things, the central piece of r151729 I seem to want is just 
> this:
>
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c  (revision 151728)
> +++ gcc/config/rs6000/rs6000.c  (revision 151729)
> @@ -18033,7 +18033,8 @@ static bool
>  no_global_regs_above (int first, bool gpr)
>  {
>   int i;
> -  for (i = first; i < gpr ? 32 : 64 ; i++)
> +  int last = gpr ? 32 : 64;
> +  for (i = first; i < last; i++)
>     if (global_regs[i])
>       return false;
>   return true;
>
> Taking only that and leaving out all of the rest of r151729 lets me
> build a powerpc gcc that does use lmw/stmw instructions in function
> prologue and epilogues as hoped.  Unfortunately it also has bad
> codegen elsewhere.  So it seems I need more than just this little
> piece of r151729.  Unfortunately, r151729 is a fairly large patch that
> seems to do a number of jobs and which does not apply readily to gcc
> 4.4.  At the moment it's not clear to me what other parts of it I
> might need.
>
> Can anyone here offer any hints or pointers on how to extract from the
> r151729 diff just the few pieces needed to fix this single powerpc
> codegen bug in gcc 4.4.3?  Anyone recognize this issue and already
> dealt with it in isolation?

The change to no_global_regs_above() is one of the key pieces, but
that change exposed other latent bugs, as you have encountered.  One
needs the additional patches to the save/restore strategy routines and
prologue/epilogue.  This is why the entire patch was committed in one
piece.

- David

RFC: Representing vector lane load/store operations

[Richard Sandiford]

This is an RFC about adding gimple and optab support for things like
ARM's load-lane and store-lane instructions.  It builds on an earlier
discussion between Ira and Julian, with the aim of allowing these
instructions to be used by the vectoriser.

These instructions operate on N vector registers of M elements each and
on a sequence of 1 or M N-element structures.  They come in three forms:

  - full load/store:

  0<=I   RGB RGB RGB RGB

  - lane load/store:

  given L, 0<=I   RGB

  - load-and-duplicate:

  0<=I

__builtin_store_lanes (VECTORS : array N of vector M of X)
  returns array N*M of X
  maps to vstN on ARM
  in practice, the argument would be populated by assignments of the form:
ARRAY_REF  = vectorY

__builtin_load_lane (REF : array N of X,
 VECTORS : array N of vector M of X,
 LANE : integer)
  returns array N of vector M of X
  maps to vldN_lane on ARM

__builtin_store_lane (VECTORS : array N of vector M of X,
  LANE : integer)
  returns array N of X
  maps to vstN_lane on ARM

__builtin_load_dup (REF : array N of X)
  returns array N of vector M of X
  maps to vldN_dup on ARM

I've hacked up a prototype of this and it seems to produce good code.
What do you think?

Richard

Re: RFC: Representing vector lane load/store operations

[Richard Guenther]

On Tue, Mar 22, 2011 at 5:52 PM, Richard Sandiford
 wrote:
> This is an RFC about adding gimple and optab support for things like
> ARM's load-lane and store-lane instructions.  It builds on an earlier
> discussion between Ira and Julian, with the aim of allowing these
> instructions to be used by the vectoriser.
>
> These instructions operate on N vector registers of M elements each and
> on a sequence of 1 or M N-element structures.  They come in three forms:
>
>  - full load/store:
>
>      0<=I
>    E.g., for N=3, M=4:
>
>         Registers                   Memory
>                     ---
>                 <--->   RGB RGB RGB RGB
>
>  - lane load/store:
>
>      given L, 0<=I
>    E.g., for N=3. M=4, L=2:
>
>         Registers                   Memory
>                     ---
>         ..R.  ..G.  ..B.    <--->   RGB
>
>  - load-and-duplicate:
>
>      0<=I
>    E.g. for N=3 V4HIs:
>
>         Registers                   Memory
>                     
>                 <   RGB
>
> Starting points:
>
>  1) Memory references should be MEM_REFs at the gimple level.
>     We shouldn't add new tree codes for memory references.
>
>  2) Because of the large data involved (at least in the "full" case),
>     the gimple statement that represents the lane interleaving should
>     also have the MEM_REF.  The two shouldn't be split between
>     statements.
>
>  3) The ARM doubleword instructions allow the N vectors to be in
>     consecutive registers (DM, DM+1, ...) or in every second register
>     (DM, DM+2, ...).  However, the latter case is only interesting
>     if we're dealing with halves of quadword vectors.  It's therefore
>     reasonable to view the N vectors as one big value.
>
> (3) significantly simplifies things at the rtl level for ARM, because it
> avoids having to find some way of saying that N separate pseudos must
> be allocated to N consecutive hard registers.  If other targets allow the
> N vectors to be stored in arbitrary (non-consecutive) registers, then
> they could split the register up into subregs at expand time.
> The lower-subreg pass should then optimise things nicely.
>
> The easiest way of dealing with (1) and (2) seems to be to model the
> operations as built-in functions.  And if we do treat the N vectors as
> a single value, the load functions can simply return that value.  So we
> could have something like:
>
>  - full load/store:
>
>      combined_vectors = __builtin_load_lanes (memory);
>      memory = __builtin_store_lanes (combined_vectors);
>
>  - lane load/store:
>
>      combined_vectors = __builltin_load_lane (memory, combined_vectors, lane);
>      memory = __builtin_store_lane (combined_vectors, lane);
>
>  - load-and-duplicate:
>
>      combined_vectors = __builtin_load_dup (memory);
>
> We could then use normal component references to set or get the individual
> vectors of combined_vectors.  Does that sound OK so far?
>
> The question then is: what type should combined_vectors have?  (At this
> point I'm just talking about types, not modes.)  The main possibilities
> seemed to be:
>
> 1. an integer type
>
>     Pros
>       * Gimple registers can store integers.
>
>     Cons
>       * As Julian points out, GCC doesn't really support integer types
>         that are wider than 2 HOST_WIDE_INTs.  It would be good to
>         remove that restriction, but it might be a lot of work.
>
>       * We're not really using the type as an integer.
>
>       * The combination of the integer type and the __builtin_load_lanes
>         array argument wouldn't be enough to determine the correct
>         load operation.  __builtin_load_lanes would need something
>         like a vector count argument (N in the above description) as well.
>
> 2. a vector type
>
>     Pros
>       * Gimple registers can store vectors.
>
>     Cons
>       * For vld3, this would mean creating vector types with non-power-
>         of-two vectors.  GCC doesn't support those yet, and you get
>         ICEs as soon as you try to use them.  (Remember that this is
>         all about types, not modes.)
>
>         It _might_ be interesting to implement this support, but as
>         above, it would be a lot of work.  It also raises some tricky
>         semantic questions, such as: what is the alignment of the new
>         vectors? Which leads to...
>
>       * The alignment of the type would be strange.  E.g. suppose
>         we're dealing with M=2, and use uint32xY_t to represent a
>         vector of Y uint32_ts.  The types and alignments would be:
>
>           N=2 uint32x4_t, alignment 16
>           N=3 uint32x6_t, alignment 8 (if we follow the convention for modes)
>           N=4 uint32x8_t, alignment 32
>
>         We don't need alignments greater than 8 in our intended use;
>         16 and 32 are overkill.
>
>       * We're not really using the type as a single vector,
>  

Re: segmentation fault with fclose

[Jeremy Hall]

Try the  "comp.lang.c.moderated" group for C and C library questions.

You probably meant:

   if( fp != NULL )
   fclose( fp );

That is, "!= NULL" rather than "== NULL".

Re: RFC: Representing vector lane load/store operations

[Richard Sandiford]

Richard Guenther  writes:
> Simple.  Just make them registers anyway (I did that in the past
> when working on middle-end arrays).  You'd set DECL_GIMPLE_REG_P
> on the decl.

OK, thanks, I'll give that a go.  TBH, I'm still hopeful we can
do without it, because we do seem to cope quite well as things stand.
But I suppose that might not hold true as the examples get more complicated.

>   4. a vector-of-vectors type
>
>  Cons
> * I don't think we want that ;)

Yeah :-)

>>    __builtin_load_lanes (REF : array N*M of X)
>>      returns array N of vector M of X
>>      maps to vldN on ARM
>>      in practice, the result would be used in assignments of the form:
>>        vectorY = ARRAY_REF 
>>
>>    __builtin_store_lanes (VECTORS : array N of vector M of X)
>>      returns array N*M of X
>>      maps to vstN on ARM
>>      in practice, the argument would be populated by assignments of the form:
>>        ARRAY_REF  = vectorY
>>
>>    __builtin_load_lane (REF : array N of X,
>>                         VECTORS : array N of vector M of X,
>>                         LANE : integer)
>>      returns array N of vector M of X
>>      maps to vldN_lane on ARM
>>
>>    __builtin_store_lane (VECTORS : array N of vector M of X,
>>                          LANE : integer)
>>      returns array N of X
>>      maps to vstN_lane on ARM
>>
>>    __builtin_load_dup (REF : array N of X)
>>      returns array N of vector M of X
>>      maps to vldN_dup on ARM
>>
>> I've hacked up a prototype of this and it seems to produce good code.
>> What do you think?
>
> How do you expect these to be used?  That is, would you ever expect
> components of those large vectors/arrays be used in operations
> like add, or does the HW provide vector-lane variants for those as well?

The individual vectors would be used for add, etc.  That's what the
ARRAY_REF stuff above is supposed to be getting at.  So...

> Thus, will
>
>   for (i=0; i X[i] = Y[i] + Z[i];
>
> result in a single add per vector lane load or a single vector lane load
> for M "unrolled" instances of (small) vector adds?  If the latter then
> we have to think about indexing the vector lanes as well as allowing
> partial stores (or have a vector-lane construct operation).  Representing
> vector lanes as automatic memory (with array of vector type) makes
> things easy, but eventually not very efficient.

...Ira would know best, but I don't think it would be used for this
kind of loop.  It would be more something like:

   for (i=0; i
green = ARRAY_REF 
blue = ARRAY_REF 
D1 = red + green
D2 = D1 + blue
MEM_REF  = D2;

My understanding is that'd we never do any operations besides ARRAY_REFs
on the compound value, and that the individual vectors would be treated
pretty much like any other.

> I had new tree/stmt codes for array loads/stores for middle-end arrays.
> Eventually the vector lane support can at least walk in the same direction
> that middle-end arrays would ;)

What's the status of the middle-end array stuff?  A quick search
showed up your paper, but is it still WIP, or has it already gone in?
(Showing my ignorance of tree-level stuff here. :-))  It does sound
like it'd be a good fit for these ops.

Richard

Target library disabling at toplevel

[Joseph S. Myers]

Why do a great many targets disable libgcj by default in the toplevel 
configure.ac?

Where GCC provides a runtime library for a given language, I'd think the 
compiler isn't particularly useful without the library - and so if the 
compiler is built for that language, an attempt should be made to build 
the library, with a build failure if it isn't supported.  This is the 
situation with Go, for example - if you try to build with Go enabled for a 
target to which libgo hasn't yet been ported, you get a build failure in 
libgo telling you that the configuration you asked for isn't yet 
supported.

Thus, I'd think that the disabling of libgcj by default on many targets 
should be removed.  If it genuinely doesn't work on a given target, then 
the right setting is

unsupported_languages="$unsupported_languages java"

though I'm not sure unsupported_languages works quite the right way (in my 
view, it should only disable inclusion of a language in 
--enable-languages=all; if you explicitly specify an unsupported language, 
it should still try to build it).  (And why (CC to maintainer) do some 
CRIS and MMIX targets list Fortran in unsupported languages?  I didn't 
think the Fortran libraries had any porting issues, unlike Java and Go and 
Ada.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Target library disabling at toplevel

[Hans-Peter Nilsson]

> Date: Tue, 22 Mar 2011 19:51:38 + (UTC)
> From: "Joseph S. Myers" 

> Why do a great many targets disable libgcj by default in the toplevel 
> configure.ac?

Maybe because the right way, through unsupported_languages,
never caught on and there never was a global conversion? :-)

> Where GCC provides a runtime library for a given language, I'd think the 
> compiler isn't particularly useful without the library - and so if the 
> compiler is built for that language, an attempt should be made to build 
> the library, with a build failure if it isn't supported.

Agreed, the library/language issue is why I added that variable
. :-)

>  (And why (CC to maintainer) do some

The archives are open, I had to search it myself, having forgot
all about this.

> CRIS

A closer inspection will show that it's only the subtarget
cris-*-aout.  IIRC support for this target was removed for GCC,
it'd probably be a good idea to do the same here at the
top-level for the other projects (newlib, binutils, gdb).  (For
the record, generating cris-aout output should still be possible
through cris-elf-objcopy.)

> and MMIX targets list Fortran in unsupported languages?  I didn't 
> think the Fortran libraries had any porting issues, unlike Java and Go and 
> Ada.)

For MMIX, the issues I mentioned at
 are
presumably fixed, but pragmatically the interest level for
fortran on MMIX is ...undetectable.  (Prove me wrong: I
challenge anyone to send gcc-testresults@ with it enabled and
the mmixware simulator installed.)  So, for the time being I'm
not prepared to add that as something that is expected to be
maintained.

brgds, H-P

Re: Target library disabling at toplevel

[Joseph S. Myers]

On Tue, 22 Mar 2011, Hans-Peter Nilsson wrote:

> > CRIS
> 
> A closer inspection will show that it's only the subtarget
> cris-*-aout.  IIRC support for this target was removed for GCC,
> it'd probably be a good idea to do the same here at the
> top-level for the other projects (newlib, binutils, gdb).  (For
> the record, generating cris-aout output should still be possible
> through cris-elf-objcopy.)

I do intend as part of toplevel cleanup following up on removal of 
deprecated targets to cleanup such cases relating to targets removed from 
GCC (since whether or not any bit of the src repository supports them, 
GCC-specific configure code for them certainly isn't needed at toplevel).

> > and MMIX targets list Fortran in unsupported languages?  I didn't 
> > think the Fortran libraries had any porting issues, unlike Java and Go and 
> > Ada.)
> 
> For MMIX, the issues I mentioned at
>  are
> presumably fixed, but pragmatically the interest level for

Those look like newlib-target issues, not MMIX-target issues, in any case.

> fortran on MMIX is ...undetectable.  (Prove me wrong: I
> challenge anyone to send gcc-testresults@ with it enabled and
> the mmixware simulator installed.)  So, for the time being I'm
> not prepared to add that as something that is expected to be
> maintained.

It's not a matter of "expected to be maintained", it's a matter of targets 
only being different from other targets where there is a clear reason for 
that difference (an important feature of the GNU toolchain is consistency 
between targets).  I expect most users of many targets to be using 
--enable-languages=c,c++ (or just c) - but I see no reason for the 
defaults for this target to be different from those for many other 
newlib-using targets.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Target library disabling at toplevel

[Ian Lance Taylor]

"Joseph S. Myers"  writes:

> Why do a great many targets disable libgcj by default in the toplevel 
> configure.ac?

I believe that it's just a hack: libgcj doesn't build on the target, but
gcc/java does.  Disabling libgcj lets the gcc configure/make complete in
a natural way.

unsupported_languages is a clearly superior approach, but it postdates
many of the cases in which libgcj is added to noconfigdirs.

Ian

debugging

[Mike Stump]

So, I was trying to debug some stuff with the top of the tree on a suse linux 
x86_64 box and got:

(gdb) p mode
Unhandled dwarf expression opcode 0xf3

which I don't find entertaining.  I know I _could_ install a new gdb, and most 
likely this would fix the problem, but, I don't want to do that right now.  I 
think gcc should avoid codes that gdb doesn't support.  I rebuilt with --O0, 
just to try and avoid the issue, and that didn't work either.  :-(

Re: debugging

[Andrew Pinski]

On Tue, Mar 22, 2011 at 3:15 PM, Mike Stump  wrote:
> So, I was trying to debug some stuff with the top of the tree on a suse linux 
> x86_64 box and got:
>
> (gdb) p mode
> Unhandled dwarf expression opcode 0xf3
>
> which I don't find entertaining.  I know I _could_ install a new gdb, and 
> most likely this would fix the problem, but, I don't want to do that right 
> now.  I think gcc should avoid codes that gdb doesn't support.  I rebuilt 
> with --O0, just to try and avoid the issue, and that didn't work either.  :-(

I think we already documented the required version of gdb.  The newer
dwarf code is needed to produce a more correct value of mode at the
point where you tried to print mode.  So you are stuck in a mess if
you disable that extension so you will not get the correct value of
mode at the point you are printing it out at or you have to download a
newer version of gdb.  I think most people would like to have correct
printing and downloading a new version of gdb is just something people
can go and do.

Thanks
Andrew Pinski

Re: debugging

[Ian Lance Taylor]

Mike Stump  writes:

> So, I was trying to debug some stuff with the top of the tree on a suse linux 
> x86_64 box and got:
>
> (gdb) p mode
> Unhandled dwarf expression opcode 0xf3
>
> which I don't find entertaining.  I know I _could_ install a new gdb, and 
> most likely this would fix the problem, but, I don't want to do that right 
> now.  I think gcc should avoid codes that gdb doesn't support.  I rebuilt 
> with --O0, just to try and avoid the issue, and that didn't work either.  :-(

I haven't looked, but you should be able to use, e.g., -gdwarf-2
-gstrict-dwarf.  If that doesn't work then something has gone wrong.

Ian

Re: Target library disabling at toplevel

[Hans-Peter Nilsson]

On Tue, 22 Mar 2011, Joseph S. Myers wrote:
> On Tue, 22 Mar 2011, Hans-Peter Nilsson wrote:
> > For MMIX, the issues I mentioned at
> >  are
> > presumably fixed, but pragmatically the interest level for
>
> Those look like newlib-target issues, not MMIX-target issues, in any case.

The issues mentioned there, yes.  But also, the mmixware
simulator is really restricted in what I/O it can do, more so
than what a src/sim simulator can do, and it's more cast in
stone than a src/sim simulator (where missing necessary support
can naturally be added as an improvement).  As the MMIX port
primarily targets this simulator, it's a MMIX-specific issue.

> > So, for the time being I'm
> > not prepared to add that as something that is expected to be
> > maintained.
>
> It's not a matter of "expected to be maintained", it's a matter of targets
> only being different from other targets where there is a clear reason for
> that difference (an important feature of the GNU toolchain is consistency
> between targets).  I expect most users of many targets to be using
> --enable-languages=c,c++ (or just c) - but I see no reason for the
> defaults for this target to be different from those for many other
> newlib-using targets.

I don't support this as an absolute truth: though needless
differences should be investigaged and fixed, I expect leverage
to be allowed the respective target maintainer.

brgds, H-P

gcc-4.4-20110322 is now available

[gccadmin]

Snapshot gcc-4.4-20110322 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110322/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch 
revision 171315

You'll find:

 gcc-4.4-20110322.tar.bz2 Complete GCC (includes all of below)

  MD5=495aacb609ed9792c94d81617249eef7
  SHA1=f67424d3420bcde7cd2e8290694dd0defef2df55

 gcc-core-4.4-20110322.tar.bz2C front end and core compiler

  MD5=78a25f562b419a0a32a7c8b5ba336f6c
  SHA1=3da9139ccde5771e591ce3e530d4a944eb9d986a

 gcc-ada-4.4-20110322.tar.bz2 Ada front end and runtime

  MD5=18ed22e0a5135a7c9afe6e35327f4f8d
  SHA1=90d8abd5d3cf5769fee83c6cc0dd5e9928be9ec1

 gcc-fortran-4.4-20110322.tar.bz2 Fortran front end and runtime

  MD5=d772f8dee8a523e39b5aefa7a2f3446c
  SHA1=f9287e7822dd699f1f4e9aed01ecc5319817ad06

 gcc-g++-4.4-20110322.tar.bz2 C++ front end and runtime

  MD5=0de615f25806617073e0f12a0c5e245c
  SHA1=3274f53b48fa9d6170bcbe159ca58451df75c068

 gcc-go-4.4-20110322.tar.bz2  Go front end and runtime

  MD5=58294cc0b1eccd3c3e3e9bd8f1810475
  SHA1=cf99fa9e019495c2ae6092a8071c54a7bdfec3f5

 gcc-java-4.4-20110322.tar.bz2Java front end and runtime

  MD5=9303d064ea8a2e8b3450dc97083bbfbb
  SHA1=97137dea70edf76ce81341fb851d3511e6c9e07f

 gcc-objc-4.4-20110322.tar.bz2Objective-C front end and runtime

  MD5=423021a5778185c4e2399670388f5e81
  SHA1=cd7705c63e83b81138e16e97d0f2b0ee40373ac4

 gcc-testsuite-4.4-20110322.tar.bz2   The GCC testsuite

  MD5=9b49e2c9c8e4de87032c8d20293a8f93
  SHA1=50db8bf16964da378ad5760db42da2d6a2bad041

Diffs from 4.4-20110315 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Cross compiler build instructions - PowerPC

[Rohit Arul Raj]

Hello All,

I have been trying to build a cross compiler (for PowerPC) on x86_64
linux host. I followed the build procedure given in the link below:

http://www.eglibc.org/archives/patches/msg00078.html

The build instructions in the link works perfectly fine with the
following revisions:
GCC v4.1.2
Binutils v2.17
linux v2.16.19.1
eglibc v2.5

But while trying to build with the latest revisions, i get some build errors:

GCC v4.5.1
Binutils v2.20.51
linux  2.6.35.2
libc 2.13 (from eglibc)

Error while building 1st stage GCC:
-

make[4]: Entering directory
`/cross_build/ppc45/obj/gcc1/powerpc-linux-gnu/nof/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.

/cross_build/ppc45/obj/gcc1/./gcc/xgcc -MD -MP -MF decContext.dep -c
/cross_build/ppc45/src/gcc-4.5-2010.09/libgcc/../libdecnumber/decContext.c
/cross_build/ppc45/src/gcc-4.5-2010.09/libgcc/../libdecnumber/decContext.c:33:43:
fatal error: string.h: No such file or directory
compilation terminated.
make[4]: *** [decContext.o] Error 1
make[4]: Leaving directory
`/cross_build/ppc45/obj/gcc1/powerpc-linux-gnu/nof/libgcc'
make[3]: *** [multi-do] Error 1

I was expecting that 'libgcc' will not be built in the first stage? Is
that right?
If i try configuring with '--disable-libgcc', i get errors while
building 'libiberty' & 'zlib'. Disabling all three does help to build
the first stage of GCC but was not sure if this was the right way to
do it.

Do we have different build instructions other than the one mentioned
in the link above to build the latest sources?

Thanks,
Rohit