Re: fatal error: gnu/stubs-32.h: No such file

[FX]

> The fact it's not listed as a prerequesite has already been pointed
> out as a problem with the docs.

As a consensual first step toward addressing this issue, I suggest the 
following patch to the doc. I hope it is clear enough, but suggestions are 
obviously welcome. (I haven't even compiled the docs with it, as I'm on my 
laptop with little battery.)

FX


Index: install.texi
===
--- install.texi(revision 201292)
+++ install.texi(working copy)
@@ -255,6 +255,26 @@ may need to use @option{--disable-stage1
 bootstrapping the compiler with such earlier compilers is strongly
 discouraged.
 
+@item C standard library and headers
+
+In order to build GCC, the C standard library and headers must be present
+for all target variants for which target libraries will be built (and not
+only the variant of the host C++ compiler).
+
+This affects the popular @samp{x86_64-unknown-linux-gnu} platform (among
+other multilib targets), for which 64-bit (@samp{x86_64}) and 32-bit
+(@samp{i386}) libc headers are usually packaged separately. If you do a
+build of a native compiler on @samp{x86_64-unknown-linux-gnu}, beware of
+either:
+
+@itemize @bullet
+@item having 32-bit libc developer package properly installed (the exact
+name of the package depends on your distro); otherwise, you may encounter an
+error such as @samp{fatal error: gnu/stubs-32.h: No such file}
+@item building GCC as a 64-bit only compiler, by configuring with the
+option @option{--disable-multilib}
+@end itemize
+
 @item GNAT
 
 In order to build the Ada compiler (GNAT) you must already have GNAT

gcc-4.9-20130728 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 201294

You'll find:

 gcc-4.9-20130728.tar.bz2 Complete GCC

  MD5=0d216831f302eba63d3a322ea13d74a6
  SHA1=7c16be3520c983e29c96ee94f870707183f02e1d

Diffs from 4.9-20130721 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
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.

Re: Problems with register elimination

[Chung-Ju Wu]

On 7/28/13 8:16 AM, David Given wrote:

I am having a great deal of trouble getting register elimination (and
stack frame layouts in general) working properly on my architecture.
There is some fundamental issue I'm simply not getting here.

[...]

Weirdness (1): I never see ARG_POINTER_REGNUM used to access arguments.
The compiler seems to want to access function arguments via
FRAME_POINTER_REGNUM plus a small value, which means they overlap the
locals. (It's definitely using the same numeric ranges. It looks like
it's trying to use ARG_POINTER_REGNUM but is getting the wrong register.)



Internally, ARG_POINTER_REGNUM is a pointer to the incoming arguments
which is pushed into stack by caller, and FRAME_POINTER_REGNUM is a
pointer to the first location of local variables.

||
   old stack pointer ->  
|| \
||   incoming arguments pushed by caller
|| /
argument pointer ->   --
||
||
||
   frame pointer ->   --
|| \
||   local variables
|| /
  --
|| \
||   outgoing arguments
|| /
   stack pointer ->  
||



Weirdness (2): the following test function generates code with tries to
copy AP_REG into a register without eliminating it.


[...]


I don't know whether this is just talking about the MCore, or gcc in
general --- I find it interesting that most backends which use a fake
frame pointer seem to end up with FRAME_POINTER_REGNO and
HARD_FRAME_POINTER_REGNO pointing at different addresses.

If anyone can offer any suggestions as to what I'm doing wrong --- or,
better still, point me at more in-depth reading on how all this is
supposed to work!



Did you implement TARGET_CAN_ELIMINATE and INITIAL_ELIMINATION_OFFSET ??

You need to implement these two target macros to eliminate ARG_POINTER_REGNUM
and FRAME_POINTER_REGNUM into HARD_FRAME_POINTER_REGNUM.


Best regards,
jasonwucj