[Bug bootstrap/38523] New: arm build fails to link cc1-dummy

[Bug bootstrap/38523] New: arm build fails to link cc1-dummy

[laurent at guerby dot net]

At trunk rev 142742 on debian arm-linux-gnueabi bootstrap fails at the end of
stage1 with:

../trunk/configure --prefix=/n/50/guerby/install-trunk --enable-languages=c
--enable-__cxa_atexit --disable-nls --enable-threads=posix
--with-mpfr=/opt/cfarm/mpfr-2.3.2
make bootstrap 
...
gcc  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -o
cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o
c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o
c-parser.o arm-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o
dummy-checksum.o \
          main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -L/opt/cfarm/mpfr-2.3.2/lib -lmpfr -lgmp  
attribs.o: In function `init_attributes':
/home/guerby/build/gcc/../../trunk/gcc/attribs.c:182: relocation truncated to
fit: R_ARM_CALL against symbol `htab_create' defined in .text section in
../libiberty/libiberty.a(hashtab.o)
/home/guerby/build/gcc/../../trunk/gcc/attribs.c:191: relocation truncated to
fit: R_ARM_CALL against symbol `htab_find_slot_with_hash' defined in .text
section in ../libiberty/libiberty.a(hashtab.o)
attribs.o: In function `lookup_attribute_spec':
/home/guerby/build/gcc/../../trunk/gcc/attribs.c:210: relocation truncated to
fit: R_ARM_CALL against symbol `htab_find_with_hash' defined in .text section
in ../libiberty/libiberty.a(hashtab.o)
c-lex.o: In function `init_c_lex':
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:81: relocation truncated to fit:
R_ARM_CALL against symbol `get_run_time' defined in .text section in
../libiberty/libiberty.a(getruntime.o)
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:85: relocation truncated to fit:
R_ARM_CALL against symbol `cpp_get_callbacks' defined in .text section in
../libcpp/libcpp.a(directives.o)
c-lex.o: In function `get_fileinfo':
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:110: relocation truncated to
fit: R_ARM_CALL against symbol `splay_tree_new' defined in .text section in
../libiberty/libiberty.a(splay-tree.o)
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:114: relocation truncated to
fit: R_ARM_CALL against symbol `splay_tree_lookup' defined in .text section in
../libiberty/libiberty.a(splay-tree.o)
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:118: relocation truncated to
fit: R_ARM_CALL against symbol `xmalloc' defined in .text section in
../libiberty/libiberty.a(xmalloc.o)
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:122: relocation truncated to
fit: R_ARM_CALL against symbol `splay_tree_insert' defined in .text section in
../libiberty/libiberty.a(splay-tree.o)
c-lex.o: In function `update_header_times':
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:134: relocation truncated to
fit: R_ARM_CALL against symbol `get_run_time' defined in .text section in
../libiberty/libiberty.a(getruntime.o)
c-lex.o: In function `dump_time_statistics':
/home/guerby/build/gcc/../../trunk/gcc/c-lex.c:154: additional relocation
overflows omitted from the output
collect2: ld returned 1 exit status
make[3]: *** [cc1-dummy] Error 1
make[3]: Leaving directory `/home/guerby/build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/guerby/build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/guerby/build'
make: *** [bootstrap] Error 2

Any idea on what to try?

Some debian build are successful, eg:

http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00520.html

But I don't know what configure/patch are critical for building on this
platform.


-- 
           Summary: arm build fails to link cc1-dummy
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: build
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: laurent at guerby dot net
 GCC build triplet: arm-linux-gnueabi
  GCC host triplet: arm-linux-gnueabi
GCC target triplet: arm-linux-gnueabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #1 from laurent at guerby dot net  2008-12-15 09:23 -------
4.3.2 bootstrap doesn't fail in stage1 so this is a trunk regression.


-- 

laurent at guerby dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |laurent at guerby dot net
      Known to work|                            |4.3.2
            Summary|arm build fails to link cc1-|[4.4 regression] arm build
                   |dummy                       |fails to link cc1-dummy


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[schwab at suse dot de]

------- Comment #2 from schwab at suse dot de  2008-12-15 09:33 -------
Probably related to bug 37739.  Building with optimisation may be a workaround.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #3 from laurent at guerby dot net  2008-12-15 11:46 -------
>From Richard Earnshaw:

<<
GCC (to be precise binutils) has limit on the maximum program size on
ARM, which is 32MBytes (based on the span of the BL instruction).
Unfortunately, when GCC is built without optimization and with checking
enabled the image exceeds this limit.  You can work around this by
configuring with --disable-stage1-checking.

See the discussion of this back in May 2007 (the initial diagnosis of
the problem was wrong :-) starting here:

http://gcc.gnu.org/ml/gcc/2007-05/msg00108.html
>>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #4 from laurent at guerby dot net  2008-12-15 15:54 -------
More discussions here:

http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00861.html

Also from Richard:

Recent binutils should also be able to generate binaries exceeding this limit, 
though there is some runtime and additional code size overhead when this 
occurs.

> I'm using debian lenny binutils 2.18.1~cvs20080103-7 and
> since I'm seeing the error I assume it's not recent enough?

Probably not. It may not be present in any released version of binutils.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[doko at ubuntu dot com]

------- Comment #5 from doko at ubuntu dot com  2008-12-16 08:49 -------
The most recent complete build logs can be seen at

http://buildd.debian.org/fetch.cgi?&pkg=gcc-snapshot&ver=20081130-1&arch=armel&stamp=1228429623&file=log
http://launchpadlibrarian.net/20414304/buildlog_ubuntu-jaunty-armel.gcc-snapshot_20081213-0ubuntu1_FULLYBUILT.txt.gz

both builds use -O for the stage1 build.

binutils 2.19 is available either in Debian experimental or in Ubuntu 8.10
(2.18.93) or in the current Ubuntu development version, but test results do not
differ if built with 2.18.x or 2.19.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #6 from laurent at guerby dot net  2008-12-17 11:13 -------
I confirm that on trunk adding to configure:

--enable-stage1-checking=release

allows a full bootstrap. I did not test STAGE1_CFLAGS="-g -O" yet.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #7 from laurent at guerby dot net  2008-12-20 12:21 -------

../trunk/configure --prefix=/n/50/guerby/install-trunk-142808
--enable-languages=c,c++ --enable-__cxa_atexit --disable-nls
--enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.3.2
--build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
--disable-werror

make bootstrap STAGE1_CFLAGS="-O1"

did work.

I assume -disable-werror can be removed since the fix was checked in:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38578


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[jakub at gcc dot gnu dot org]

------- Comment #8 from jakub at gcc dot gnu dot org  2009-01-01 11:19 -------
arm could just add x-cflags-O1 to host_xmake_file in gcc/config.host,
see what powerpc*-*-linux* host is doing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #9 from laurent at guerby dot net  2009-01-02 10:11 -------
Thanks Jakub, I'm testing:

Index: gcc/config.host
===================================================================
--- gcc/config.host     (revision 142984)
+++ gcc/config.host     (working copy)
@@ -125,6 +125,9 @@
         ;;
     esac
     case ${host} in
+      arm*-*-linux-gnueabi )
+        host_xmake_file="${host_xmake_file} x-cflags-O1"
+        ;;
       *-*-linux* )
        if test "${GCC}:${ac_cv_sizeof_long}" = yes:4; then


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[jakub at gcc dot gnu dot org]

------- Comment #10 from jakub at gcc dot gnu dot org  2009-01-02 11:23 -------
That won't work, this is surrounded by:
case ${host} in
  rs6000-*-* \
  | powerpc*-*-* )

You want to do it at the same level, so:
--- config.host2008-12-27 10:12:25.000000000 +0100
+++ config.host2009-01-02 12:23:10.000000000 +0100
@@ -146,6 +146,9 @@ case ${host} in
 ;;
     esac
     ;;
+  arm*-*-linux-gnueabi )
+    host_xmake_file="${host_xmake_file} x-cflags-O1"
+    ;;
 esac

 # Machine-specific settings.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #11 from laurent at guerby dot net  2009-01-02 11:56 -------
Yep I spotted my obvious mistake :), the patch I'm testing:

Index: gcc/config.host
===================================================================
--- gcc/config.host     (revision 143006)
+++ gcc/config.host     (working copy)
@@ -148,6 +148,13 @@
     ;;
 esac

+case ${host} in
+  arm*-*-linux-gnueabi )
+    # To avoid stage1 link failure due to linker limitations.
+    host_xmake_file="${host_xmake_file} x-cflags-O1"
+    ;;
+esac
+
 # Machine-specific settings.
 case ${host} in
   alpha*-dec-*vms*)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #12 from laurent at guerby dot net  2009-01-04 10:42 -------
My second patch testing was successful but it added a lot of time to C only
make bootstrap: 20h => 25h30, so about +25% vs --enable-stage1-checking=release

What should we do?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2009-01-05 11:26 -------
Disable stage1 checking for arm.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Priority|P3                          |P2
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-05 11:26:40
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #14 from laurent at guerby dot net  2009-01-05 12:05 -------
Something like that? (untested)

Index: configure.ac
===================================================================
--- configure.ac        (revision 143046)
+++ configure.ac        (working copy)
@@ -2904,6 +2904,9 @@
 else
   stage1_checking=--enable-checking=$enable_checking,types
 fi])
+case "${host}" in
+  arm*-*-linux-gnueabi) stage1_checking=--enable-checking=release;;
+esac
 AC_SUBST(stage1_checking)

 # Enable -Werror in bootstrap stage2 and later.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #15 from laurent at guerby dot net  2009-01-13 12:05 -------
Add URL of gcc-patches discussion

http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00409.html


-- 

laurent at guerby dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2009-
                   |                            |01/msg00409.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #16 from laurent at guerby dot net  2009-01-14 21:12 -------
binutils 2.19 and CVS do not seem to cure the issue, I opened:

http://sourceware.org/bugzilla/show_bug.cgi?id=9743


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[danglin at gcc dot gnu dot org]

------- Comment #17 from danglin at gcc dot gnu dot org  2009-02-18 21:54 -------
Configuring with --disable-stage-checking, I see the following for cc1:

-bash-3.2$ size cc1
    text           data     bss      dec            hex filename
28977798         496932  623152 30097882        1cb41da cc1

Given the branch distance limit for arm, --disable-stage-checking
is probably not a great solution.  The text size for arm seems very
large.  It's more than twice the size of text on hppa.  In fact,
all the sizes are much bigger than on hppa:

dave@hiauly6:~/gnu/gcc-4.4/objdir/stage1-gcc$ size cc1
    text           data     bss      dec            hex filename
13321030         168288  334952 13824270         d2f10e cc1

Long branch stub placement seems broken even with binutils head.
Possibly, building with -ffunction-sections is the work around.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4/4.5 regression] arm build fails to link cc1-dummy

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.0                       |4.4.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4/4.5 regression] arm build fails to link cc1-dummy

[rearnsha at gcc dot gnu dot org]

------- Comment #18 from rearnsha at gcc dot gnu dot org  2009-04-21 16:40 -------
(In reply to comment #14)
> Something like that? (untested)
> 
> Index: configure.ac
> ===================================================================
> --- configure.ac        (revision 143046)
> +++ configure.ac        (working copy)
> @@ -2904,6 +2904,9 @@
>  else
>    stage1_checking=--enable-checking=$enable_checking,types
>  fi])
> +case "${host}" in
> +  arm*-*-linux-gnueabi) stage1_checking=--enable-checking=release;;
> +esac
>  AC_SUBST(stage1_checking)
> 
>  # Enable -Werror in bootstrap stage2 and later.
> 

Rather than doing this for linux-gnueabi only, this should be triggered for all
arm targets.  ie arm*-*-*

R.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4/4.5 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #19 from laurent at guerby dot net  2009-04-21 17:05 -------
I believe current binutils is very near to have this issue fixed, I'm pinging
on the binutils bugzilla.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4/4.5 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #20 from laurent at guerby dot net  2009-04-23 14:24 -------
binutils from CVS 20090423 successfully link stage1 cc1 without any special
option (no --enable-checking-release and no -O1), my build on gcc55 is
currently in stage3

$ ../trunk/configure --prefix=/n/55/guerby/install-trunk- --enable-languages=c
--enable-__cxa_atexit --disable-nls --enable-threads=posix
--with-mpfr=/opt/cfarm/mpfr-2.3.2 --disable-multilib
$ make bootstrap

No objection to closing this PR?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523

[Bug bootstrap/38523] [4.4/4.5 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

------- Comment #21 from laurent at guerby dot net  2009-05-04 14:50 -------
No objection in one week, so closing as WORKSFORME with binutils from CVS >=
20090423


-- 

laurent at guerby dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523